At 14:38 -0500 on 08/10/2006, Tom Marchant wrote about Re: Vendor JCL
(was: WHY IS JCL ALLERGIC ... ):
On Wed, 9 Aug 2006 23:09:16 -0400, Robert A. Rosenberg <[EMAIL PROTECTED]>
wrote:
At 18:08 -0500 on 08/09/2006, Tom Marchant wrote about Re: Vendor JCL
(was: WHY IS JCL ALLERGIC ... ):
I can assure you that many vendors produce inferior SMP/E. SMP/E is a
powerful tool, and when the SYSMODs are coded correctly, it makes
installing and maintaining a system easy.
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
There is no such thing as an "element SUP chain."
OK - Poor nomenclature. What I was getting at is that when I do an
APPLY, I am superseding the RMID ownership of the element and
assigning that of the new SYSMOD. Thus I have SUP'ed the old copy of
the Element and supplied a new copy.
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.
Elements from the sysmod being restored *always* come from the DLIB zone.
Why should they when there is a newer valid copy available in another
SYSMOD in APPLY Status?
You and I can disagree about the design of RESTORE. I don't have a problem
with the way it works. I've heard arguments similar to your many times,
but I have seldom had a problem with it. Prior to a RESTORE, it is
sometimes necessary to ACCEPT service up to the one(s) that I want to
restore. While that this can be a nuisance with a product that has had
many ++ZAPs applied to a module, most of the time it is not such a big deal.
Tom Marchant
Can you justify the forced need to do unnecessary work just to back
off a SYSMOD. To make it simple, here is a scenerio:
The initial state of the Target Zone is no SYSMODs in APPLY status. I
now do an APPLY step that APPLYs 10 SYSMODs that are inter-related in
that after I am done, there is at least one element that was updated
that came from each of the 10 SYSMODs. Now I want to RESTORE one of
the SYSMODs and all of the elements that are contained in it
currently have its RMID as their owner (IOW: The SYSMOD is not SUPed
or PREd and we could have successfully done the APPLY of only 9 of
the SYSMODs by omitting it). With the current Brain-Dead design of
RESTORE I am forced to remove ALL 10 of the SYSMODs and then reAPPLY
9 of them just to back off the 10th instead of just taking its
elements from whichever of the remaining 9 SYSMODs had the latest
version (or if none had a copy, using the copy from the DLIB).
Please explain why the current methodology is "better" than just
identifying which SYSMODs would have supplied those elements in the
to-be-RESTOREd SYSMODs if it had never been APPLYed and just
reAPPLYing them (along with those extra elements that were in those
SYSMODs that PRE the to-be-RESTOREd SYSMODs [ie: Those that APPLYed
only because the to-be-RESTOREd SYSMODs were either simultaneously
being APPLYed or were already in APPLY status]). NOTE: I am assuming
that no BYPASS(ID) "magic" was done to force the APPLY to work in
violation of the PRE/SUP Chain.
----------------------------------------------------------------------
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
