At 10:36 -0500 on 08/11/2006, Rick Fochtman wrote about Re: Vendor
JCL (was: WHY IS JCL ALLERGIC ... ):
-----------------------<snip>-------------------------
That is until you have to RESTORE a SYSMOD at while point SMP/E
causes you to do lots of useless work. The intent of a RESTORE is to
create a system as if that SYSMOD (and possibly SYSMODs that PRE it)
had not yet been APPLYed. The CORRECT way of doing a RESTORE
operation is to determine which elements must be backed off and which
SYSMODs contain the replacement versions of the elements. The current
implementation causes you to have to remove (and subsequently
reAPPLY) SYSMODS that have nothing to do with the one being RESTOREd.
As a simple example, SYSMOD1 contains elements A, B, and C while
SYSMOD2 contains only element B and PREs SYSMOD1. Both are currently
in APPLY status. To RESTORE SYSMOD2, I must also RESTORE SYSMOD1 (and
possibly SYSMOD3 which PREs SYSMOD1 since it contains a newer copy of
A and/or C but not B). All that is needed is to just reAPPLY element
B from SYSMOD1 and you have RESTOREd SYSMOD2 but SMP/E goes through
useless work to back off A and C also (along with other elements in
SYSMODs on the PRE chain that is anchored at SYSMOD1) only to then do
an APPLY (sans SYSMOD2) of all the erroneously RESTOREd SYSMODs. If
all you want to do is RESTORE B, you should run the element SUP chain
on B until you find a copy to APPLY/use (in this case the copy in
SYSMOD1) and ignore everything else. RESTORE is a flawed design since
it involves elements that are not affected when the correct versions
are available from SYSMODs still in APPLY status or from the DLIB
copy of the element.
----------------------------<unsnip>----------------------------
NEVER assume SYSMODS are unrelated. Control block changes and dependancies can
cause changes in things that appear to be completely unrelated, but
mis-matches
in code in CSECTS/RSECTS that use those blocks can have DISASTROUS
consequences.
I am NOT assuming that SYSMODs are unrelated. I am just following the
PRE/SUP indications in the SYSMOD Statements as supplied. If I do the
RESTORE the current way and back off 10 SYSMODS only to do the APPLY
and apply 9 of them, why is this "safer"/"more correct" than just
doing a forward APPLY of those element(s) of the backed-off SYSMOD
that were taken from the other 9 SYSMODs during the Apply step that
was done after the Restore? Note what my "Correct" RESTORE does - It
asks what SYSMOD supplied the element(s) that is/are being replaced
by the to-be-RESTOREd SYSMOD and says to back off the element(s) by
using those from the PREd/SUPd SYSMOD WITHOUT affecting any Element
that is not in the SYSMOD (or one that PREs it).
If you can not follow what I said in the quote above, I will list a
string of SYSMODs (with elements) and show how my method "follows the
packaging rules" yet is more efficient than the RESTORE-and-APPLY
method currently forced by a poor design of the RESTORE function.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
