IBM Support

Application Dependencies - SPE 9.3.0.6 APARs PI62520 , PI62521, PI74544 and PI75825 and PI78683

Troubleshooting


Problem

The new SPE to allow dependencies between applications is available. Are there any concerns regarding the installation of this SPE?

Resolving The Problem

Revised January 24, 2018 for additional information concerning PI78683 .

Revisions marked with vertical bar " | " on left side .

Here is a brief description of this SPE:


You can specify that operations and applications are dependent on other operations and applications, as follows:

An operation depends on another operation. (existing)
An operation depends on an application. (new!)
An application depends on another application. (new!)
An application depends on an operation of another application. (new!)

The PI74544 APAR includes some enhancements and fixes related to the
original APARS PI62520 and PI62521 and well so it is recommended to
apply the PTFs for this APAR as well.

The PTFS for PI62520, PI62521, and PI74544 (IWS z/OS 9.3 only) are:

All languages/implementations:

UI43560
UI43566
UI43567
UI43573
UI44895
UI44901

Language specific:

UI43568 UI43561 UI44896 Korean
UI43569 UI43562 UI44897 English
UI43570 UI43563 UI44898 German
UI43571 UI43564 UI44899 Kanji
UI43572 UI43565 UI44900 Spanish

The documentation specific to this SPE is stored here:

http://www.ibm.com/support/knowledgecenter/SSRULV_9.3.0/com.ibm.tivoli.itws.doc_9.3/common/src_gi/eqqg1zosenh_SpeDec16.htm

The online versions of the IWSz manuals have also been refreshed with all changes related to this
SPE. The updates manuals are available at:

ftp://public.dhe.ibm.com/software/tivoli/workload_scheduler_zos/9.3/

| Note if this symptom is seen after applying UI43566 then apply the fix
| for HIPER PI78683 (PTF UI46103):
| Set to complete can incorrectly leave successors in wait
| status

Note in order to use the USRLEV parameter from the INIT statement (for example
from EQQYPARM in a PIF job) it is necessary to first apply the fix for APAR PI75825
which is PTF UI45022 .

Note: If you installed the original version of this APARFIX YI75825 from February 2 you
will need to obtain the UI45022 PTF and do an APPLY REDO in order to
be able to install the UI44901 PTF.

If you do not apply UII45022 you may see this error in the EQQMLOG of a PIF job:

IKJ56712I INVALID KEYWORD, USRLEV(10)

Also note that if UI44901 is not applied your controller EQQMLOG may become
filled with messages like:

EQQZ024I MCCPY copy OPR

Please see below some further clarification about the ACTION HOLDS related to these PTFs



(1) PTF UI43566 contains this HOLD:

ACTION:
Since this apar introduces a change to
EQQZRMG1, that is part of the load module EQQSSCMM,
in order to correctly apply the fix, the user
needs to reload the new EQQSSCMM, either doing a system IPL
or restarting the controller starter task
adding the following options to the OPCOPTS statement:
BUILDSSX(REBUILD)
SSCMNAME(EQQSSCMM,PERMANENT)
These parameters should be removed at the next restart of the
controller.
(end)

However this HOLD is actually for a PRE-REQUISITE PTF UI41194.
If you have ALREADY applied UI41194 before applying the SPE PTFs,
you can ignore this hold- the SPE code does NOT change the subsystem
module EQQSSCMM, so no BUILDSSX/SSCMNAME override is needed.
However if you install UI41194 at the same time as the SPE PTFs then you
need to follow this ACTION HOLD as always.

(2) PTF UI43566 does cause a new version of the dialog main module EQQMINOM
to be linked. There is no ACTION HOLD concerning this- however, if you do NOT have
the entire SEQQLMD0 library in your LINK LIST but have just copied at some previous time
the load module EQQMINOM into your LNKLST, you need to perform this action AGAIN
so that your link list will contain the most current version of EQQMINOM.

(3) PTF UI43567 contains two ACTION HOLDS:

This APAR changes some TWSz ISPF variable tables.
Consider to reset the ISPF profile through
the 0.0 TWSz options.

To allow PIF to handle Application dependencies
you need to set the parameter USRLEV in the INIT
statement to 10.

Concerning the first hold (0.0) this would need to be done by EVERY dialog
user.

The need to do the 0.0 for EVERY dialog user has been confirmed and an "AI"
or additional information has been added to PTF Ui43567

If you want to automate this so that the 0.0 will be done for each user the
first time they log on to IWSz after the SPE is installed, refer to the section
"AUTOMATIC REINIT" below.

For the new PIF parameter on the INIT statement (USRLEV) check the
documentation links listed above.

Some additional information about the need for the USRLEV parameter follows:

If controller has PI57310 applied and PIF was compiled PRIOR to applying PI57310
then USRLEV does NOT need to be specified.

If controller has PI57310 applied and PIF was compiled AFTER applying PI57310
then USRLEV(9) must be specified.

If controller has PI62520/PI62521 applied and PIF was compiled BEFORE applying PI57310
then USRLEV does not need to be specified.

If controller has PI62520/PI62521 applied and PIF was compiled AFTER applying PI57310
but BEFORE applying PI62520/PI62521 then USRLEV(9) must be specified.

If controller has PI62520/PI62521 applied and PIF was compiled AFTER applying PI62520/PI62521
then USRLEV(10) must be specified.


So in other words USRLEV only has to be used when PIF source is
recompiled, not just because the PTFs have been applied



Also as noted in PI62520:

Note: Currently, the Dynamic Critical
Path, DWC and WAPL do not support
Application Dependencies.

To enable this feature, PIF users
are required to set the parameter
USRLEV in the INIT statement to 10.

AUTOMATIC REINIT

This suggestion if implemented should be tested first in a "sandbox" or test environment.

In order to have the 0.0 REINIT of the profile performed for ALL dialog users the first time
they access the new SPE code, the following modification can be done concurrently
to panels EQQOPCAP and EQQXINIP. So to begin with you need to copy both
EQQOPCAP and EQQXINIP from the panel library (SEQQPENU) modified by the SPE
into a separate library that is concatenated ahead of SEQQPENU in the ISPPLIB
concatenation. Then make these changes:

In EQQOPCAP:

000097 IF (&OFRSTT ¬= PI62521) /* to new rel|SET TO APAR LEV@71C@81C@91C*/
000098 .RESP = ENTER /* make sure it will be */
000099 &ZCMD = 0.0 /* It is option 0.0 */
000100 &OFRSTT = PI62521 /*Prevent looping||SET TO APAR LE@71C@81C@91C*/

(that is, change V9R3M0 to PI62521 on lines 97 and 100)

In EQQXINIP:

000157 &rel = V9R3M0 /* release field @6CC@77C@92C
000158 &ofrstt = PI62521 /* should have the latest APAR lev@6CC@77C@92C

(this is, change V9R3M0 to PI62521 on line 158)

If both these panels are changed as indicated above, when a dialog user who has been
using the 9.3 dialog BEFORE the SPE was installed logs on to the dialog AFTER the
SPE is installed (including the 2 panels shown above), the 0.0 reinit will be done
automatically ONE time - the next time they log on to the IWSz dialog, the value
for &OFRSTT will already have been stored as PI62521, so no REINIT will be done.

[{"Product":{"code":"SSRULV","label":"IBM Workload Scheduler for z\/OS"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"--","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"9.3.0","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
13 September 2019

UID

swg21997214