Dynamic Resources

The concept of dynamic resources was introduced to primarily address automated (DevOps) deployment scenarios for single address spaces, for example, APLs representing CICS and IMS regions and USS resources. Its purpose is to have one or more predefined templates in the policy that can be used by operators or automation to dynamically bring these resources into the scope of SA z/OS® without running through a policy build and refresh cycle.

The general steps to use dynamic resources and a few things to consider are as follows. This process enables you to apply enterprise policies to the content of a template via the existing change control mechanisms, while giving additional speed and flexibility to create resources at runtime based on template definition.
Figure 1. Clickable dynamic resource roadmap
Set up the datastore Define TEMPLATE applications Build and refresh Create or delete dynamic resources Turn dynamic resources to static resources
  1. Set up the backend database to store dynamic resources.

    System Automation offers two options to store dynamic resources: its internal data store and IBM Db2 for z/OS (the later option is enabled in OA63123). Technically, dynamic APL resources are persisted in the backend database rather than the policy and automation control file. Therefore, it is a prerequisite to run through the documented setup for the backend database when you plan to use dynamic resources.

    You need to choose between the two database options. You cannot switch back and forth between the database. Once you choose between anyone, the data would be fetched and inserted into the database chosen.

    Note: If the database is not available, INGDYN will issue an error. Also, in a policy refresh or automation restart scenario, the creation of dynamic resources depends on the availability of the database. In case of issues with the database availability, the automation of dynamic resources is delayed in such a refresh or restart scenario until the database is available again.
  2. Define one or more APLs with type TEMPLATE in the Customization Dialog.
    Note:
    • Templates support only limited CLASS inheritance. If class inheritance is used, relationships, trigger, service periods, runtoken, and desired available status are not inherited. Since templates can be considered as a 'class concept' itself, it is recommended to specify everything on the template.
    • Dynamic resources cannot be supporting resources for other resources.
    • If you link a template to a service period (SVP), ensure that the SVP is already linked to a resource, such as an APL, APG, or MTR. SVP is not generated into the ACF at build time if it is used only with templates. Therefore, if you link a template to an SVP that's not linked to any resource, the dynamic resource that is created based on that template will not include the linked service period.
    • If you link a template to a pacing gate, ensure that the pacing gate is already linked to at least one static APL instance or class. Otherwise, the pacing gate is not generated for the template.
  3. Build and refresh the configuration. No automation resources are created at build time. However, the template information is made available to the agents on all systems in the SAplex.
  4. Operators can use the INGDYN command at runtime to create dynamic APL resources based on the available templates. No build and refresh is needed.
    Note:
    • A dynamic resource that is created by INGDYN is initially placed into a suspended state. It is expected that an operator or other automation (for example, via INGDYN AOFEXC29 exit) resumes the newly created resource.
    • If a dynamic resource is added to a hosting APG during INGDYN creation processing and this group is a MOVE or SERVER group, the resource will be added as an 'operator' role for model 2 groups and with preference value 1 for model 1 groups. It is expected that an operator or other automation sets the expected role or preference value via INGGROUP command before resuming it.
  5. (Optional) You might need to turn a dynamic resource to a static resource and add its definitions in the policy. When turning a dynamic resource to a static resource, you need to manually delete the dynamic resource.
    Static resources and dynamic resources are both stored in the data model of automation managers and agents. In addition, dynamic resources are also stored in the backend database, either in the System Automation internal datastore or IBM Db2/OS. Automation managers and agents uniquely identify static and dynamic resources by their names. If you add a static resource with the same name as a dynamic resource, the dynamic resource will be overwritten by the static one in the data model of automation managers and agents. Additionally, the record of the dynamic resource is not removed automatically from the datastore; therefore, you have to manually delete it. For this reason, when turning a dynamic resource to static, follow these ordered steps:
    1. Assume that there is a dynamic resource, for example, OI1M0405, previously created with INGDYN.
    2. Create a static resource with the same name OI1M0405 in the policy database.
    3. Build the policy database.
    4. Before refreshing the policy, use the INGDYN DELETE command to delete the dynamic resource OI1M0405. This command will delete it from both the data model of automation managers and agents and the datastore.
    5. Issue INGAMS REFRESH to load the automation control file containing the static resource OI1M0405.

In summary, dynamic resources enable you to apply enterprise policies to the content of a template via the existing change control mechanisms, while giving additional speed and flexibility to create resources at runtime based on template definition.