OPS/MVS

 View Only
  • 1.  SSMGA and sysplex boundary limitations

    Broadcom Employee
    Posted Sep 26, 2019 03:57 PM
    All, I am asking for any use cases you may have that the existing SSMGA V2 solution cannot address due to being limited to sysplex boundary.  The current SSMGA V2 application leverages the CA Common Services Sysplex Variable service (CAVARSRV).  Do you currently have an unsatisfied use case to provide resource mobility beyond the syplex boundaries?  Do you have a homegrown solution to address the need to provide resource mobility beyond sysplex boundaries.  Would a vendor-supplied resource mobilty application with the ability to extend across sysplex boundaries be of interest?  If so, please describe your use cases in your comments below.

    ------------------------------
    Ron Sheehan
    Mainframe Engineering Services Architect
    Broadcom
    ------------------------------


  • 2.  RE: SSMGA and sysplex boundary limitations

    Posted Sep 30, 2019 08:27 AM
    We have our own homegrown end user utilities  to ​ 'provide resource control/monitoring beyond sysplex boundaries', allowing us to have a focal point of control/monitoring of all SSM resources across 18 sysplexes using MSF of course to communicate across the 70+ systems. We currently don't have a need to move resources around as a system IPLs or fails as SSMGA  within a plex provides, but if we did, probably just create our own end user SSMMOVE type of action driven REQ rule that moves things around by setting and firing a focal  )GLV rule that process the plex var update with the info of resource,prereqs, where to move,etc. A recent thought of a future enhancement/idea that we have to still provide in Ideation (but did mention during a recent demo of controlling GLVPLX* vars from OPSVIEW 4.8) that may easily allow you to expand SSMGA (as well as user applications that exploit Sysplex variables) across sysplexes, is to make the OPSVASRV() MSF supportable. Right now we can accomplish this by triggering pgms via OPSRMT to, but builtin cross system capabilities on the function is of course more optimal. Thus, you could piggy back on MSF via a SYSTEM() keyword on the function to manipulate sysplex variables across sysplexes, creating a true 'OPSPLEX' within all MSF connected systems.