Explore how to mirror the z/OS current plan to a database to enable the Orchestration Monitor1/27/2025 Managing large-scale data operations often comes with significant performance challenges. When query requests are handled directly by the Z controller the system might suffer from a slowdown, thus impacting the user experience. To address this issue, you can now replicate data from the z/OS current plan data set to a database. In this way, your queries are processed directly on the database with no impact on the Z controller. You can also keep history of the updated objects to a maximum of 7 days earlier, thus enabling better analytics and troubleshooting. Let’s find out more! To enable the mirroring of the z/OS current plan, ensure that you are running the Dynamic Workload Console V10.2.3 or later, and Z controller V10.2 or later. As the first customization step, set the MIRROPTS statement in the controller's EQQPARM library... …. then customize the fed_variables.xml file included in the Dynamic Workload Console package. What’s new? Federator (FM): a new component, which is included in the Dynamic Workload Console package. The Federator manages the communication towards the database where the data taken from the z/OS current plan is stored. DB Filler: a new subtask in the Z controller. The DB Filler manages the communication and data exchange towards the Federator. Mission: Event Possible! In this context, the communication between the DB Filler and Federator is managed through events. These events handle the transfer of three main objects: jobs, jobstreams, and workstations. The Bulk event plays a critical role, ensuring efficient and complete data uploading into the database. Data stored in the database is accessible from the Orchestration Monitor, which you can now use to monitor and perform actions on z/OS objects. Before data can be uploaded into the database through the Bulk event, an essential preliminary phase takes place: registration of the Z controller to the Federator. During the registration process, the DB Filler registers itself to the Federator, establishing a trusted connection. After the registration completes, the Federator generates an authentication token, which is passed to the Z controller. In this way, the authentication token becomes the key to secure and validate any future requests, ensuring smooth and reliable communication between the components. From the Orchestration Monitor, you can perform actions on the objects. Thanks to the Dynamic event, whenever a change is made to the z/OS current plan, it is reflected in real-time both in the database and Orchestration Monitor. Exciting news Rest API V2 and Federator Swagger The Orchestration Monitor introduces a revamped experience powered by the latest REST APIs Version 2, delivering enhanced performance and a modernized approach to executing requests. One of the most appreciated features are the improved Swagger interfaces, designed to simplify interactions. A new Swagger is now exposed on the Z connector… ….while another has been introduced by the Federator. This addition empowers users to run queries directly on the database, leveraging the flexibility of the OQL language syntax for filtering results. With these updates, managing and querying your data has never been faster or more intuitive. What are the benefits?
To find additional information, see the topic "Mirroring the z/OS current plan to enable the Orchestration Monitor" of the Dynamic Workload Console User's Guide. A 90-second video is also available at the following link: Mirroring the z/OS current plan to enable Orchestration Monitor
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
October 2024
Categories
All
|