At 01:57 -0400 on 08/12/2006, Arthur T. wrote about Re: Vendor JCL
(was: WHY IS JCL ALLERGIC ... ):
On 11 Aug 2006 21:02:35 -0700, in bit.listserv.ibm-main
(Message-ID:<[EMAIL PROTECTED]>)
[EMAIL PROTECTED] (Robert A. Rosenberg) wrote:
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?
I've cursed SMP for the same reasons. However, I can think of
reasons that the current method is safer or more correct:
1. If you've Received Holddata between the Apply and Restore, it
may be that one of those other Sysmods is PEd, SUPed, or some such.
See my reply to point 3 below. I do not think that it is hard to do a
scan to see if Holddata issued AFTER the date of the APPLY would have
blocked the APPLY (I think that the date of the APPLY is stored in
the element's entry as well as each HOLDDATA entry having a similar
"issued" date).
2. If any of the 10 had JCLIN, things could get tricky. Especially
tricky if the one you're Restoring had JCLIN.
ONLY if the To-be-Restored SYSMOD has JCLIN (or is PRE'ed by another
SYSMOD with JCLIN). Note that my method automatically merges an
SYSMODs that PRE the named SYSMODs and treats them as if they were
listed in the SELECT clause. So long as the SYSMODs to be backed off
have no JCLIN, there is no problem since any LMODs get created the
same (just possibly with earlier versions of the backed off elements).
3. SMP won't know if you did any BYPASSes when Applying. If you
had, things could get tricky. Better that a person do trickiness
than trusting it to SMP.
I am only addressing what I perceive as a basic design flaw in the
original implementation. To avoid the potential problems you list,
I'd agree to a RESTORE CHECK option - ie: Do the Restore as a Check
followed by an under-the-covers APPLY CHECK suppressing the SELECTED
SYSMODs to see if the result is the same as just backing off the
relevant elements. The result is a report that says either that just
"Forward APPLY'ing" (ie: Doing an APPLY only with prior versions of
the elements in the SYSMODs) will result in the same state as the
current RESTORE/APPLY process would or that one or more SYSMODs will
not go on (probably due to newer HOLDS) and list the reasons (similar
to the current APPLY CHECK BYPASS report).
Also, IBM has limited resources for SMP enhancements. I
suspect it would be easier to code SMP to Restore all 10, then
automatically re-Apply the other 9. (Or, at least, automatically
create the control cards for doing so.)
----------------------------------------------------------------------
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
