Ferragosto Edition
“Better late than never” – Apologies for the one-month lateness of this, but it was summer in North Carolina back in July, which was both the hottest month and wettest month in many years (if not for all time) but succeeded in early August by fall-like weather . I remember saying to a friend “I fell asleep in summer and woke up in October”. I have sat down several times to write this, but decided to wait until DWC release 10.2.5 was available as there was not too much else new to write about. 10.2.5 was released August 4 and I have not yet found the time to install it, however I am looking forward to mirroring with z/OS DB2 (mirroring with non-z/OS Db2 has been available since 10.2.3 back in November 2024.
I decided to postpone the usual sections about HIPERs, technotes, blogs, etc until the next newsletter which will be on time in October.
With the 10.2.5 release comes the latest set of PDF manuals at:
https://www.ibm.com/docs/en/workload-automation/10.2.5?topic=product-library-in-pdf-format
This has the “distributed” Workload Automation manuals at 10.2.5 level plus the z Workload Scheduler 10.2 manuals, revised for 10.2 SPE 2 (luly 2025). The section in the Customization and Tuning Guide on the MIRROPTS statement has a good definition of what mirroring is about:
The MIRROPTS statement defines the parameters to register and connect a Z controller to the Federator that is automatically installed with the Dynamic Workload Console V10.2.3, or later. Upon registration completion, your current plan data is replicated (mirrored) to the database referenced by the Federator, to enable you to run queries through the Orchestration Monitor or the REST APIs V2. Note: Optionally, you can have the Z controller connected to a load balancer that dispatches and redirects the connections among several instances of the same Federator.
For details about how to replicate the CP objects to the Federator, see “Mirroring the z/OS current plan to enable the Orchestration Monitor”
To over-simplify a bit, instead of a RESTAPI call needing to go through a zconnector to a server task running on z/OS, to a zWS controller to get data that is then sent back by the server and zconnector, the data from the current plan is automatically “pushed” into a DB2 database that is accessed by the RESTAPI call. This should be a big performance improvement.
WE INTERRUPT THIS DISCUSSION OF NEW zWS FUNCTIONALITY TO COVER LATE-BREAKING MIGRATION EVENTS DUE TO zWS 9.5 going out of support after September 30, 2025…
I didn’t think I would need to do this so late into the life-cycle of 9.5 however support cases are being opened frequently about migrating from 9.5 and even 9.3 to 10.1 or 10.2. Support extensions for 9.5 are still possible, and the services teams can assist with or even do a “turnkey” migration, however level 2 zWS support is still offering assistance via a “proactive” migration case- however this must be opened at LEAST 2 weeks prior to the actual planned migration date. As the term “proactive” suggests, the purpose of the case is to try to prevent common mistakes or omissions that can cause a migration to fail.
If you need this, please open a case for z Workload Scheduler at severity 4 and include the following documentation:
- Your written migration plan document
- All of your zWS task EQQMLOGs for your current release (only one tracker MLOG is needed)
- Output from a CP EXTEND or LT EXTEND job (BATCHOPT parameter) for your current release
- Your EQQICNVS JCL (PGM=EQQICTOP)
Be really careful with event datasets (EQQEVDS) as there have been changes in this area – no more sharing of EQQEVDS, no DASD connected trackers (for 10.2 release). No need to reallocate the EQQEVDS for a tracker (please re-read the Migration chapter (chapter 6) of the latest Planning and Installation Guide if this is a surprise for you- there have been many revisions/improvements).
WE NOW REJOIN OUR REGULARLY SCHEDULED PROGRAMMING…
There will be a lot more information about DWC mirroring, changes to historical DB2 reporting feature and RESTAPI V2 in the next newsletter and via technotes. Technotes already are using the keyword “ZWSTECHNOTE” to make them easier to find. I will add “V10R2M5” also to any technotes which are pertinent to the latest modifications to the product at 10.2.5 level.
The first of these is:
ZWSTECHNOTE : DWCZOS : V10R2M5 How to obtain and install DWC 10.2.5 to run on z/OS ?:
https://www.ibm.com/support/pages/node/7241385
The RELEASE NOTES for 10.2.5 are here: ibm.com/support/pages/node/7240670
ZWS 10.2 MAINTENANCE NEWS:
The latest SPE for 10.2 ( SPE10202 ) is APAR PH66793 and the PTFs are available:
UO04142 UO04143 UO04144 plus language related PTFs:
UO04145 Korean
UO04146 English
UO04147 German
UO04148 Kanji
UO04149 Spanish
Some of the recent 10.2 PTFs have an ACTION HOLD that requires a 0.0 REINIT be done for dialog users – UO03422, UO04146, UO04271. For an easy way to accomplish this without all of your dialog users having to remember to do 0.0 see “AUTOMATIC 0.0 REFRESH” below
The ACTION HOLDS for UO04142 require a careful read. This technote will have the latest information:
https://www.ibm.com/support/pages/node/7238375
Especially important is that the historical reporting feature ( EQQRXARC ) now requires IBM Semeru Runtime Certified Edition Java Technology Edition) V17 or V21. Prior to this PTF the history function only worked with Java V8.
AUTOMATIC 0.0 REFRESH
Be careful with any modifications to panels EQQXINIP and EQQOPCAP as an “endless loop” in the ISPF dialog can occur if these modifications are not coordinated properly. EQQXINIP is a “non-display” panel whose purpose is to set up variables stored in the ISPF profile which are then used by EQQOPCAP (the main panel for the zWS dialog) as well as other panels.
As distributed in SEQQPENU for the 10.2 release
EQQOPCAP:
IF (&OFRSTT ¬= V10R2M0) /*init to new rel|SET TO APAR LEV@A0C@81C@93C*/
.RESP = ENTER /* make sure it will be */
&ZCMD = 0.0 /* It is option 0.0 */
&OFRSTT = V10R2M0 /*Prevent looping||SET TO APAR LE@A0C@81C@91C*/
EQQXINIP
&ofrstt = V10R2M0 /* should have the latest APAR lev@A0c@6CC@77C@93C
If you change every instance of OFRSTT in BOTH panels from V10R2M0 to another value like UO04271, a 0.0 REINIT will be done when entering the zWS dialog for the first time since the panel modifications were made. If another PTF later on has the same requirement, for example UO09999 changing UO04271 to UO09999 will cause the REINIT again. Of course you must make the changes to a separate panel library concatenated ahead of SEQQPENU in the ISPPLIB concatenation – never change the contents of any SEQQxxxx file.
CONCLUSION
That’s all for now. See you again in October, where in North Carolina it is likely to be summer-like with temperatures in the 90s (Fahrenheit) unless there is an early frost or maybe even some snow. The saying here is “If you don’t like the weather, wait 10 minutes. It will change.”
