Cavendum Idibus Martiis – Beware of the Ides of March

This may have been good advice for Julius Caesar but for the rest of us the Ides of March in 2019 was a happy occasion – the general availability of the V9.5 was released under a new name.

Introducing IBM Z Workload Scheduler 9.5

Recent Updates & Technotes

List of HIPER PTFs for IBM Workload Scheduler for z/OS 9.3 – The list includes new HIPERs added as of March 8, 2019. To be absolutely certain of having ALL HIPER maintenance, it is best to go to the enhanced HOLDDATA website and download recent HOLDDATA.

As of May 2020 the only supported releases will be IBM Workload Scheduler for z/OS 9.3 and IBM Z Workload Scheduler 9.5 (This statement is based on the information available as of March 11, 2019.)

Recent PMR Trends

Some customers are still experiencing issues, which could prevented by following the FLASH for PI93525 (PTFs UI55004 / UI55005 ) correctly. Get ahead of the issue (if you have not done so already) and follow FLASH for PI93525 (PTFs UI55004 / UI55005 ).

Benefits of the Migration Program for 9.5

As I mentioned in the last newsletter, the migration program (PGM=EQQICTOP) for IBM Z Workload Scheduler 9.5 eliminates the need to run a REPLAN with the controller down.  Five (5) other trends include:

  1. Not having HIPER maintenance applied
  2. Having a mismatch in code level across the IBM Z Workload Scheduler environment: I am not sure why we are seeing so much of this item as of late. All the IBM Z Workload Scheduler started tasks (controller, tracker, etc), the batch LT and CP jobs, and the ISPF dialog need to use the same level of the IBM Z Workload Scheduler code (the SEQQLMD0 library in particular). Yet, we are seeing many cases where the started tasks all have the same SEQQLMD0, but the batch jobs and the ISPF dialog have different ones as well.  This type of problem may be more prevalent in test or “sandbox” environments than it is in production environments, but these non-production environments are frequently where issues reported by PMRs occur.  If you see a situation with IBM Z Workload Scheduler that you have never seen before, then check that the SEQQLMD0 is consistently allocated – especially if you have just applied any PTFs.  Also be sure that any ACTION HOLDS required by the PTFs have been addressed.
  3. JTARC (EQQJTARC) file filling up (B37 abend): The JTARC file has to be large enough to hold all the tracking (JT) records between two CP REPLAN or CP EXTEND jobs (since these jobs copy EQQJTARC into tracklog (EQQTROUT) and set EQQJTARC to be empty). Once the JTARC is full the JT LOG ARCHIVER subtask fails (EQQZ045E message) and when all the EQQJTxx files have become full and cannot be archived the NORMAL MODE MANAGER (NMM) subtask will fail also. I have opened several RFEs in this area, because taking the wrong actions after the JTARC has become full can lead to very serious problems. (See the RFE section below.)

First of all, I  recommend making the EQQJTARC file larger than you think it needs to be. If you see that the file is becoming more than 50% full you should probably make it larger. There may be times where there is more tracking data generated than normal; such as, when the CP batch is not run daily (i.e. long holiday weekends) or there is a big increase in the amount of IWSZ activity. If the EQQJTARC does become full do NOT try running a REPLAN or CP EXTEND to empty the JTARC into the EQQTROUT. This might seem like a good idea; however, once the JTARC is full a CP SWITCH cannot be performed and the first thing a REPLAN or CP EXTEND does is – you guessed it  – perform a CP switch.   It is also not currently possible to restart the JT LOG ARCHIVER subtask after the JTARC has filled up. Even if you are able to free up some disk space, the JTARC cannot get take an additional extent. If the JTARC becomes full, then  follow the instructions in the Customization and Tuning Guide, chapter “Backup and Recovery of data sets” / section “Recovering from errors on the JT archive log” which are outlined below. Note: IBM continuously updates manuals; therefore,  it is best to check the manual in the event that there is a documentation change in this section.

If there is a write error on the JT archive log, follow this procedure:

    • Stop IBM Workload Scheduler for z/OS.
    • Rename the data set to a temporary name.
    • Allocate a new JT archive-log data set.
    • Copy the old data set into the new data set. This can be done by IEBGENER or IDCAMS REPRO.
    • Start IBM Workload Scheduler for z/OS.

This is the perfect time to make the EQQJTARC file much larger than it was before.

  1. S0C4 abends in module EQQZHTCL: This module is used for zcentric agents and remote workstations (shadow jobs). There have been a number of reports about abends in EQQZHTCL – either S0C4  or a language environment (LE) abend like U4039 or U4042. The LE abend is often preceded by an S0C4 abend, so it is important to capture the S0C4 dump as this type of problem tends to be very sporadic and difficult, if not impossible, to recreate.

See my technote to assist with getting the S0C4 dump.

There is an APAR for the S0C4 abend – PH09018 – which is still open. Once a PTF is available it will be set HIPER. An APARFIX for PH09018 is available. Open a PMR to request a copy, if you do not want to wait for the PTF to be available.

  1. WAPL Issues
  • Cy’s Corner 96 Correction:  The old WAPL proc name, EQQYXTOP, was incorrectly used in place of EQQYXJPX. The original blog post has been corrected as follows: “Getting to the latest WAPL maintenance level is highly recommended. Also note that the original WAPL proc EQQYXJCL has been replaced by a simplified version EQQYXJPX.  The EQQYXJCL proc is still being provided (so far) for compatibility purposes.“

NOTE:  The above has been in the 9.3 WAPL User’s Guide manual for some time, since the use of EQQYXJCL is deprecated.  This occurred in the 9.5 release; therefore, there is no longer any EQQYXJCL sample. Even if you are running 9.3 you should still switch to the EQQYXJPX or EQQYXJPL samples. If you do not want to replace all the references to EQQYXJCL, then you can copy the new EQQYXJPX proc into your EQQYXJCL proc. Be aware, however, that the following variables, which passed to EQQYXJCL, do NOT pass to EQQYXJPX:

      • FILESPEC
      • LANG
      • OPTFILE
      • OPTS
      • REF

These variables will need to be removed or replaced with “fake” references to these keywords in the proc to avoid getting a JCL error. It might be just as easy to change EQQYXJCL to EQQYXJPX.  Note: The EQQOPTS DD is still provided as a comment in EQQYXJPX, so you might need to UNCOMMENT this line and point it to your WAPL options member if you still need it.

WAPL-related PTFs for PH06660 – UI60968 and UI60969: The PTFs for PH06660 (UI60968 and UI60969) supersede almost all of the previous WAPL related PTFs. To ensure WAPL is completely up to date (as of March 11, 2019), install the following PTFs:

      • UI55006
      • UI57850
      • UI58035
      • UI58129
      • UI60968
      • UI60969

WAPL-related PTF for APAR PH05291 – UI60287: There is one other PTF which is still OPEN – UI60287 for APAR PH05291. If you apply this maintenance and start using EQQYXJPX instead of EQQYXJCL you will avoid a number of issues and it will be easier to diagnose any other issues that you may still encounter.

Requests for Enhancement (RFE)

  • RFE # 125221to make UI55005 PTF installation easierwas accepted and incorporated into 9.5. With UI55005 n the 9.5 base level code, the need for special handling has been removed.
  • EQQJTARC-related RFEs: There are hree RFEs, which relate EQQJTARC (see Benefits of Migration Program for 9.5 Item 3 above):
    1. 97396: Need restart of JT LOG ARCHIVER subtask
    2. 126448: Avoid writing over unarchived JT files after message EQQN180W is issued by controller
    3. 130548: Change EQQN180W to EQQN180E and terminate NMM immediately

More on 9.5

DB2 History Function:The DB2 history function in previous versions, which was located on the main panel EQQOPCAP, has been removed removed.

7 OLD OPERATIONS    – Restart old operations from the DB2 repository

Since the DB2 history function in 9.5 has been around for a while, hopefully this does not come as a surprise. (For more detail refer to “Reporting with IBM Workload Scheduler for z/OS”)

Some new columns were added at the 9.3 level for the “new” DB2 tables. When using DB2 for z/OS and migrating from 9.1 or 9.2 level to 9.3 or 9.5, an EQQMIGRE job needs to run. If using a non-z/OSDB2, then one of the following script needs to run:

      • dbmigrate_91.bat (for Windows)
      • dbmigrate_91.sh (for UNIX and Linux)

The Planning and Installation documentation includes the details. See “Migrating DB2 reporting”, which is located in the “Migration” chapter.

Deep in the Heart of Workload Automation

9.5 brings several time-saving and agile features and functionalities to help you streamline and automate job scheduling, enhance end-user reporting, and increase security for your organization. I along with expert users, members of the  L2 and L3 teams, and business partners are putting the final touches on their technical classes for ASAP University 2019 – Deep in the Heart of Workload Automation in order to provide you with invaluable training and network to help you move your organization forward.  I hope to see you there!