Hello zOSMF TechXchange,

Seeking some advice for a configuration of zOSMF in a SYSPLEX environment.

There are 5 PROD LPAR's, 3 DEVL LPAR's, 2 GDPS LPAR's and , 3 TEST LPAR's (TEST not in the SYSPLEX)  - I'm trying to envision a zOSMF configuration.  Where do I 'plant' the zOSMF STC's across this configuration?  I think one STC in each 'group' of PROD DEVL GDPS TEST servers but guidelines in the documentation suggest just one STC for the entire SYSPLEX.  We inherited the SYSPLEX and I would have like an architecture where these systems were split out into their own SYSPLEX environments (PROD DEVL GDPS TEST) but this site has all 10 (PROD DEVL GDPS) in one SYSPLEX.  It would have been nice to have the 3 TEST in their own SYSPLEX for testing, crashing, burning.  Currently, someone has planted one STC as a 'driver' server (AUTOSTART=LOCAL) in the 'group's (PROD DEVL GDPS) group.  I looked at this configuration as (PROD DEVL GDPS TEST) but the SYSPLEX and it's members are the rule in considering the zOSMF configuration I think as the documentation outlines. 

In these logical 'group's, would I start a 'secondary' server (AUTOSTART=CONNECT) that communicate with the main server (AUTOSTART=LOCAL) that communicates with the other LPARs?  Or, is only the one STC in the group is all that is needed for all 10 LPARs (PROD DEVL GDPS)?  Having a separate TEST zOSMF STC would be nice for thorough testing but they are not 'group'd as a SYSPLEX. 

Anyone have a suggestion would be greatly appreciated!  I'm new to setting up this configuration but appreciate anyone's advice - especially as I consider the zOSMF Ansible for use to manage workflows for distributing maintenance, products, and for auto-ipl when testing is needed.  I might be reaching here with Ansible but I thought that is what it is useful as the SysProg team could on-demand the IPL from Ansible after distributing their new software maintenance or products for testing in the TEST LPAR's. 

Thank you to anyone reading my ramblings.    

Hi Lynn,

Generally speaking, there should be one z/OSMF that manages the entire SYSPLEX.  If I understand your environment, each of your test systems is an isolated system, therefore each of them would have their own z/OSMF.

You would want to configure the z/OSMF System table in the z/OSMF for your SYSPLEX to include all of the systems in your SYSPLEX so z/OSMF's plugins know how to target them for different actions.  You can also add your test systems to the System table, identifying their individual respective z/OSMF end-points.  I believe that would allow you to target them for software maintenance and distribution.

Depending on what you want to be able to do from your Test systems, you would configure their respective System tables accordingly.

Kurt Quackenbush is the SME regarding software maintenance and distribution using z/OSMF's Software Management and Software Update plugins. 

John Czukkermann
z/OSMF Development

Hello zOSMF TechXchange,

Seeking some advice for a configuration of zOSMF in a SYSPLEX environment.

There are 5 PROD LPAR's, 3 DEVL LPAR's, 2 GDPS LPAR's and , 3 TEST LPAR's (TEST not in the SYSPLEX)  - I'm trying to envision a zOSMF configuration.  Where do I 'plant' the zOSMF STC's across this configuration?  I think one STC in each 'group' of PROD DEVL GDPS TEST servers but guidelines in the documentation suggest just one STC for the entire SYSPLEX.  We inherited the SYSPLEX and I would have like an architecture where these systems were split out into their own SYSPLEX environments (PROD DEVL GDPS TEST) but this site has all 10 (PROD DEVL GDPS) in one SYSPLEX.  It would have been nice to have the 3 TEST in their own SYSPLEX for testing, crashing, burning.  Currently, someone has planted one STC as a 'driver' server (AUTOSTART=LOCAL) in the 'group's (PROD DEVL GDPS) group.  I looked at this configuration as (PROD DEVL GDPS TEST) but the SYSPLEX and it's members are the rule in considering the zOSMF configuration I think as the documentation outlines. 

In these logical 'group's, would I start a 'secondary' server (AUTOSTART=CONNECT) that communicate with the main server (AUTOSTART=LOCAL) that communicates with the other LPARs?  Or, is only the one STC in the group is all that is needed for all 10 LPARs (PROD DEVL GDPS)?  Having a separate TEST zOSMF STC would be nice for thorough testing but they are not 'group'd as a SYSPLEX. 

Anyone have a suggestion would be greatly appreciated!  I'm new to setting up this configuration but appreciate anyone's advice - especially as I consider the zOSMF Ansible for use to manage workflows for distributing maintenance, products, and for auto-ipl when testing is needed.  I might be reaching here with Ansible but I thought that is what it is useful as the SysProg team could on-demand the IPL from Ansible after distributing their new software maintenance or products for testing in the TEST LPAR's. 

Thank you to anyone reading my ramblings.    

Hi Lynn,

Generally speaking, there should be one z/OSMF that manages the entire SYSPLEX.  If I understand your environment, each of your test systems is an isolated system, therefore each of them would have their own z/OSMF.

You would want to configure the z/OSMF System table in the z/OSMF for your SYSPLEX to include all of the systems in your SYSPLEX so z/OSMF's plugins know how to target them for different actions.  You can also add your test systems to the System table, identifying their individual respective z/OSMF end-points.  I believe that would allow you to target them for software maintenance and distribution.

Depending on what you want to be able to do from your Test systems, you would configure their respective System tables accordingly.

Kurt Quackenbush is the SME regarding software maintenance and distribution using z/OSMF's Software Management and Software Update plugins. 

John Czukkermann
z/OSMF Development

Hello zOSMF TechXchange,

Seeking some advice for a configuration of zOSMF in a SYSPLEX environment.

There are 5 PROD LPAR's, 3 DEVL LPAR's, 2 GDPS LPAR's and , 3 TEST LPAR's (TEST not in the SYSPLEX)  - I'm trying to envision a zOSMF configuration.  Where do I 'plant' the zOSMF STC's across this configuration?  I think one STC in each 'group' of PROD DEVL GDPS TEST servers but guidelines in the documentation suggest just one STC for the entire SYSPLEX.  We inherited the SYSPLEX and I would have like an architecture where these systems were split out into their own SYSPLEX environments (PROD DEVL GDPS TEST) but this site has all 10 (PROD DEVL GDPS) in one SYSPLEX.  It would have been nice to have the 3 TEST in their own SYSPLEX for testing, crashing, burning.  Currently, someone has planted one STC as a 'driver' server (AUTOSTART=LOCAL) in the 'group's (PROD DEVL GDPS) group.  I looked at this configuration as (PROD DEVL GDPS TEST) but the SYSPLEX and it's members are the rule in considering the zOSMF configuration I think as the documentation outlines. 

In these logical 'group's, would I start a 'secondary' server (AUTOSTART=CONNECT) that communicate with the main server (AUTOSTART=LOCAL) that communicates with the other LPARs?  Or, is only the one STC in the group is all that is needed for all 10 LPARs (PROD DEVL GDPS)?  Having a separate TEST zOSMF STC would be nice for thorough testing but they are not 'group'd as a SYSPLEX. 

Anyone have a suggestion would be greatly appreciated!  I'm new to setting up this configuration but appreciate anyone's advice - especially as I consider the zOSMF Ansible for use to manage workflows for distributing maintenance, products, and for auto-ipl when testing is needed.  I might be reaching here with Ansible but I thought that is what it is useful as the SysProg team could on-demand the IPL from Ansible after distributing their new software maintenance or products for testing in the TEST LPAR's. 

Thank you to anyone reading my ramblings.    

Hi Lynn,

I got your email but TechXchange is giving me no way to reply to you directly.  While I want to answer you as quickly as I can, I also want to respect that your subsequent question was asked directly.
I will reply directly as soon as I can figure out how.

John

Hi Lynn,

Generally speaking, there should be one z/OSMF that manages the entire SYSPLEX.  If I understand your environment, each of your test systems is an isolated system, therefore each of them would have their own z/OSMF.

You would want to configure the z/OSMF System table in the z/OSMF for your SYSPLEX to include all of the systems in your SYSPLEX so z/OSMF's plugins know how to target them for different actions.  You can also add your test systems to the System table, identifying their individual respective z/OSMF end-points.  I believe that would allow you to target them for software maintenance and distribution.

Depending on what you want to be able to do from your Test systems, you would configure their respective System tables accordingly.

Kurt Quackenbush is the SME regarding software maintenance and distribution using z/OSMF's Software Management and Software Update plugins. 

John Czukkermann
z/OSMF Development

Hello zOSMF TechXchange,

Seeking some advice for a configuration of zOSMF in a SYSPLEX environment.

There are 5 PROD LPAR's, 3 DEVL LPAR's, 2 GDPS LPAR's and , 3 TEST LPAR's (TEST not in the SYSPLEX)  - I'm trying to envision a zOSMF configuration.  Where do I 'plant' the zOSMF STC's across this configuration?  I think one STC in each 'group' of PROD DEVL GDPS TEST servers but guidelines in the documentation suggest just one STC for the entire SYSPLEX.  We inherited the SYSPLEX and I would have like an architecture where these systems were split out into their own SYSPLEX environments (PROD DEVL GDPS TEST) but this site has all 10 (PROD DEVL GDPS) in one SYSPLEX.  It would have been nice to have the 3 TEST in their own SYSPLEX for testing, crashing, burning.  Currently, someone has planted one STC as a 'driver' server (AUTOSTART=LOCAL) in the 'group's (PROD DEVL GDPS) group.  I looked at this configuration as (PROD DEVL GDPS TEST) but the SYSPLEX and it's members are the rule in considering the zOSMF configuration I think as the documentation outlines. 

In these logical 'group's, would I start a 'secondary' server (AUTOSTART=CONNECT) that communicate with the main server (AUTOSTART=LOCAL) that communicates with the other LPARs?  Or, is only the one STC in the group is all that is needed for all 10 LPARs (PROD DEVL GDPS)?  Having a separate TEST zOSMF STC would be nice for thorough testing but they are not 'group'd as a SYSPLEX. 

Anyone have a suggestion would be greatly appreciated!  I'm new to setting up this configuration but appreciate anyone's advice - especially as I consider the zOSMF Ansible for use to manage workflows for distributing maintenance, products, and for auto-ipl when testing is needed.  I might be reaching here with Ansible but I thought that is what it is useful as the SysProg team could on-demand the IPL from Ansible after distributing their new software maintenance or products for testing in the TEST LPAR's. 

Thank you to anyone reading my ramblings.    

Hi John, 

Getting nowhere with zOSMF server configuration (2.5.0) and trying to connect zOWE servers.  A colleague is going to go from zOWE 2.15 to zOWE 2.18 before he can then make another upgrade to zOWE 3.x something. Meanwhile, zOSMF stays at 2.5.0 with the zOS - upgrade to zOS comes in the spring or summer. 

Our current dilemma with this convoluted thing is every attempt we make, following the zOSMF doc (IBM z/OS Management Facility - IBM Documentation) and the zOWE doc (Installing Zowe | Zowe Docs) always results in an error.  One example, we tried following the installation of the JWT (Enabling JSON Web Token support - IBM Documentation), followed to the exact documentation but this results in the zOSMF server throwing a warning message:

CWWKG0028A: Processing included configuration resource: /global/zosmf/configuration/server_override.xml 

CWWKF0009W: The server has not been configured to install any features.    
CWWKF0012I: The server installed the following features: [ ].              

This is just one of the features, following these simple documentation references disables the entire server, no logon, no features.  What is trick in enabling any of the features of zOSMF to allow the zOWE to communicate with it.  My colleagues are clamoring to forget it, it's dysfunctional and to simply enact zOSFM Lite server all over the place where the need zOWE.  I'm trying to stay on course with the singular zOSMF server on one LPAR with the other LPAR's sharing it from zOWE on each LPAR (PROD DEVL TEST).  

Is there any type of 'cookbook' that has actual, working samples of configurations that work?  I'm starting to believe this is going to be D.O.A.  here.  

Thanks for any observations or recommendation you can make!

Regards,

Lynn Edward Gilson

Hi Lynn,

I got your email but TechXchange is giving me no way to reply to you directly.  While I want to answer you as quickly as I can, I also want to respect that your subsequent question was asked directly.
I will reply directly as soon as I can figure out how.

John

Hi Lynn,

Generally speaking, there should be one z/OSMF that manages the entire SYSPLEX.  If I understand your environment, each of your test systems is an isolated system, therefore each of them would have their own z/OSMF.

You would want to configure the z/OSMF System table in the z/OSMF for your SYSPLEX to include all of the systems in your SYSPLEX so z/OSMF's plugins know how to target them for different actions.  You can also add your test systems to the System table, identifying their individual respective z/OSMF end-points.  I believe that would allow you to target them for software maintenance and distribution.

Depending on what you want to be able to do from your Test systems, you would configure their respective System tables accordingly.

Kurt Quackenbush is the SME regarding software maintenance and distribution using z/OSMF's Software Management and Software Update plugins. 

John Czukkermann
z/OSMF Development

Hello zOSMF TechXchange,

Seeking some advice for a configuration of zOSMF in a SYSPLEX environment.

There are 5 PROD LPAR's, 3 DEVL LPAR's, 2 GDPS LPAR's and , 3 TEST LPAR's (TEST not in the SYSPLEX)  - I'm trying to envision a zOSMF configuration.  Where do I 'plant' the zOSMF STC's across this configuration?  I think one STC in each 'group' of PROD DEVL GDPS TEST servers but guidelines in the documentation suggest just one STC for the entire SYSPLEX.  We inherited the SYSPLEX and I would have like an architecture where these systems were split out into their own SYSPLEX environments (PROD DEVL GDPS TEST) but this site has all 10 (PROD DEVL GDPS) in one SYSPLEX.  It would have been nice to have the 3 TEST in their own SYSPLEX for testing, crashing, burning.  Currently, someone has planted one STC as a 'driver' server (AUTOSTART=LOCAL) in the 'group's (PROD DEVL GDPS) group.  I looked at this configuration as (PROD DEVL GDPS TEST) but the SYSPLEX and it's members are the rule in considering the zOSMF configuration I think as the documentation outlines. 

In these logical 'group's, would I start a 'secondary' server (AUTOSTART=CONNECT) that communicate with the main server (AUTOSTART=LOCAL) that communicates with the other LPARs?  Or, is only the one STC in the group is all that is needed for all 10 LPARs (PROD DEVL GDPS)?  Having a separate TEST zOSMF STC would be nice for thorough testing but they are not 'group'd as a SYSPLEX. 

Anyone have a suggestion would be greatly appreciated!  I'm new to setting up this configuration but appreciate anyone's advice - especially as I consider the zOSMF Ansible for use to manage workflows for distributing maintenance, products, and for auto-ipl when testing is needed.  I might be reaching here with Ansible but I thought that is what it is useful as the SysProg team could on-demand the IPL from Ansible after distributing their new software maintenance or products for testing in the TEST LPAR's. 

Thank you to anyone reading my ramblings.    

Lynn,  I think this is going to now be very difficult to sort out after I inadvertently ghosted you in March (thank you Microsoft Outlook...).

I am going to focus on the JWT issue, mainly because I have never configured zOWE, so I can't be any help there anyway.

I took the rudimentary step of going to one of my 2.5 test VMs that is setup with z/OSMF and no JWT support.  I issue the POST /zosmf/services/authenticate before changing anything and confirmed all I get back is an LTPA2 SSO cookie.  I copied the /usr/lpp/zosmf/defaults/servers/zosmfServer/server_override.cfg file to /global/zosmf/configuration/server_override.cfg (if I were doing this for real, I would softlink /usr/lpp file to the z/OSMF server configuration directory so I would pick up any potential service changes without additional manual steps).  Please note that I did not attempt to change server.xml in that directory and I did not change server_override.cfg either.

I restarted the z/OSMF server, which initialized successfully and allowed me to login to the desktop.  I examined the /global/zosmf/data/logs/zosmfServer/logs/messages.log to inspect the installed features, where I found the JWT feature as expected.

I re-issued the POST /zosmf/services/authenticate and successfully received a JWT token cookie.

Your result of conflicting features leaves me very puzzled.  Could you please send me a direct message and attach your server.xml and server_override.xml.  I don't see how you could be getting a feature conflict unless your installation is very down-level, or somehow you've tried to change the contents of server.xml and/or server_override.xml.  Under normal circumstances, neither of those files should be altered.

Hi John, 

Getting nowhere with zOSMF server configuration (2.5.0) and trying to connect zOWE servers.  A colleague is going to go from zOWE 2.15 to zOWE 2.18 before he can then make another upgrade to zOWE 3.x something. Meanwhile, zOSMF stays at 2.5.0 with the zOS - upgrade to zOS comes in the spring or summer. 

Our current dilemma with this convoluted thing is every attempt we make, following the zOSMF doc (IBM z/OS Management Facility - IBM Documentation) and the zOWE doc (Installing Zowe | Zowe Docs) always results in an error.  One example, we tried following the installation of the JWT (Enabling JSON Web Token support - IBM Documentation), followed to the exact documentation but this results in the zOSMF server throwing a warning message:

CWWKG0028A: Processing included configuration resource: /global/zosmf/configuration/server_override.xml 

CWWKF0009W: The server has not been configured to install any features.    
CWWKF0012I: The server installed the following features: [ ].              

This is just one of the features, following these simple documentation references disables the entire server, no logon, no features.  What is trick in enabling any of the features of zOSMF to allow the zOWE to communicate with it.  My colleagues are clamoring to forget it, it's dysfunctional and to simply enact zOSFM Lite server all over the place where the need zOWE.  I'm trying to stay on course with the singular zOSMF server on one LPAR with the other LPAR's sharing it from zOWE on each LPAR (PROD DEVL TEST).  

Is there any type of 'cookbook' that has actual, working samples of configurations that work?  I'm starting to believe this is going to be D.O.A.  here.  

Thanks for any observations or recommendation you can make!

Regards,

Lynn Edward Gilson

Hi Lynn,

I got your email but TechXchange is giving me no way to reply to you directly.  While I want to answer you as quickly as I can, I also want to respect that your subsequent question was asked directly.
I will reply directly as soon as I can figure out how.

John

Hi Lynn,

Generally speaking, there should be one z/OSMF that manages the entire SYSPLEX.  If I understand your environment, each of your test systems is an isolated system, therefore each of them would have their own z/OSMF.

You would want to configure the z/OSMF System table in the z/OSMF for your SYSPLEX to include all of the systems in your SYSPLEX so z/OSMF's plugins know how to target them for different actions.  You can also add your test systems to the System table, identifying their individual respective z/OSMF end-points.  I believe that would allow you to target them for software maintenance and distribution.

Depending on what you want to be able to do from your Test systems, you would configure their respective System tables accordingly.

Kurt Quackenbush is the SME regarding software maintenance and distribution using z/OSMF's Software Management and Software Update plugins. 

John Czukkermann
z/OSMF Development

Hello zOSMF TechXchange,

Seeking some advice for a configuration of zOSMF in a SYSPLEX environment.

There are 5 PROD LPAR's, 3 DEVL LPAR's, 2 GDPS LPAR's and , 3 TEST LPAR's (TEST not in the SYSPLEX)  - I'm trying to envision a zOSMF configuration.  Where do I 'plant' the zOSMF STC's across this configuration?  I think one STC in each 'group' of PROD DEVL GDPS TEST servers but guidelines in the documentation suggest just one STC for the entire SYSPLEX.  We inherited the SYSPLEX and I would have like an architecture where these systems were split out into their own SYSPLEX environments (PROD DEVL GDPS TEST) but this site has all 10 (PROD DEVL GDPS) in one SYSPLEX.  It would have been nice to have the 3 TEST in their own SYSPLEX for testing, crashing, burning.  Currently, someone has planted one STC as a 'driver' server (AUTOSTART=LOCAL) in the 'group's (PROD DEVL GDPS) group.  I looked at this configuration as (PROD DEVL GDPS TEST) but the SYSPLEX and it's members are the rule in considering the zOSMF configuration I think as the documentation outlines. 

In these logical 'group's, would I start a 'secondary' server (AUTOSTART=CONNECT) that communicate with the main server (AUTOSTART=LOCAL) that communicates with the other LPARs?  Or, is only the one STC in the group is all that is needed for all 10 LPARs (PROD DEVL GDPS)?  Having a separate TEST zOSMF STC would be nice for thorough testing but they are not 'group'd as a SYSPLEX. 

Anyone have a suggestion would be greatly appreciated!  I'm new to setting up this configuration but appreciate anyone's advice - especially as I consider the zOSMF Ansible for use to manage workflows for distributing maintenance, products, and for auto-ipl when testing is needed.  I might be reaching here with Ansible but I thought that is what it is useful as the SysProg team could on-demand the IPL from Ansible after distributing their new software maintenance or products for testing in the TEST LPAR's. 

Thank you to anyone reading my ramblings.