SMP/E APARs IR44571/IR46256 (does sup have all elements?)
Kurt Quackenbush
discussed, so let me refresh your memories and then provide some
status. APAR IR44571 changed SMP/E processing to be more strict in
ensuring PTFs contained all of the elements contained in any APARs and
PTFs that it supersedes (recall msg GIM32501E). It caused quite a
commotion back in June and July, which I'm sure many of you remember, so
SMP/E PE'd this APAR and removed this strict checking with APAR
IR46256. At that time, we had full intentions of reimplementing some
form of the original checking, but not quite as strict. Well, we have
finally developed a solution to the original problem reported by
IR44571, but this solution should not negatively impact existing or new
PTFs and APARs. This latest solution is addressed by new SMP/E APAR
IR46970, and I do believe everyone will be happier than with the
original. Let me explain the processing we will be implementing:
For a SYSMOD to properly supersede another SYSMOD, all the elements in
the superseded SYSMOD must be contained in either the superseding
SYSMOD, or in a requisite for the superseding SYSMOD (unless the element
is being deleted by the superseding SYSMOD). In this context, a
requisite SYSMOD is any SYSMOD specified on the ++VER statement REQ or
PRE operands, or on a ++IF REQ statement. Furthermore, any elements in
a requisite SYSMOD must of course be at the appropriate service level.
If all elements from the superseded SYSMOD are not contained in the
superseding SYSMOD or in one of its requisites, or not at the
appropriate service level in a requisite, then SMP/E will fail APPLY and
ACCEPT processing for the superseding SYSMOD with message GIM32501E.
For those familiar with IBM packaging rules, the above description is an
extension and clarification of rule 8000 from the MVS Standard Packaging
Rules. The packaging rules is but one documentation change that will be
made as a result; various SMP/E books will be updated as well.
So the intent of this post is as a follow-up to the previous
discussions, and to let all who might be interested know how SMP/E is
finally addressing this issue. Let me know if there are any questions
or concerns.
Kurt Quackenbush
IBM, SMP/E Development
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Bob Richards
Thanks for updating all of us on the list.
--- Kurt Quackenbush <ku...@US.IBM.COM> wrote:
snippage
> Well, we have finally developed a solution to the original problem
> reported by IR44571, but this solution should not negatively impact
> existing or new PTFs and APARs. This latest solution is addressed by
> new SMP/E APAR IR46970, and I do believe everyone will be happier
> than with the original
snippage
=====
+---------------------------------+-----------------------------+
| Bob Richards | OS/390 Consultant - Chicago |
| Internet: richa...@yahoo.com | 3D Business Solutions |
+---------------------------------+-----------------------------+
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
p...@sweng.stortek.com
> Date: Wed, 17 Oct 2001 06:30:53 -0700
>
> Good work, Kurt!
>
> Thanks for updating all of us on the list.
>
> --- Kurt Quackenbush <ku...@US.IBM.COM> wrote:
> snippage
> > Well, we have finally developed a solution to the original problem
> > reported by IR44571, but this solution should not negatively impact
> > existing or new PTFs and APARs. This latest solution is addressed by
> > new SMP/E APAR IR46970, and I do believe everyone will be happier
> > than with the original
> snippage
>
Thanks from us, also. This appears to meet our needs fully. But
you're optimistic when you "believe everyone will be happier" :-)
But if this operates as Kurt describes, it should satisfy all who
have structured their maintenance conscientiously. If we're still
impacted, it would appear to be a defect on our side, which we're
prepared to fix.
Thanks again,
gil
--
StorageTek
INFORMATION made POWERFUL
p...@sweng.stortek.com
I need some clarification.
In a recent note, Kurt Quackenbush said:
> Date: Tue, 16 Oct 2001 16:31:15 -0400
>
> PTFs that it supersedes (recall msg GIM32501E). It caused quite a
> finally developed a solution to the original problem reported by
> IR44571, but this solution should not negatively impact existing or new
> PTFs and APARs. This latest solution is addressed by new SMP/E APAR
> IR46970, and I do believe everyone will be happier than with the
> original. Let me explain the processing we will be implementing:
> In this context, a
> requisite SYSMOD is any SYSMOD specified on the ++VER statement REQ or
> PRE operands, or on a ++IF REQ statement.
>
o What happens if a PRErequisite sysmod is unavailable and the
customer has specified BYPASS(PRE)? Does the GIM32501E then
occur? This doesn't bother me -- I feel that those who
BYPASS(PRE) deserve whatever happens to them. But I'll check
with my C/T leads to see whether this gives them any heartburn,
and whether they want BYPASS(PRE) also to suppress any
GIM32501E failures.
o Is the definition of "requisite" intended to be transitive?
I.e. are PRErequisites of PRErequisites etc. examined to the
end of the chain? This is intuitive, and I'd hope for it,
but your text doesn't say that.
o And a complex but likely scenario:
SYSMOD Elements Dependencies
PTF1 MODA MODB MODC
PTF2 MODA MODB PRE(PTF1)
PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
PTF4 MODA MODB PRE(PTF2,PTF3) SUP(PTF1)
Customer has APPLYed PTF1 and wishes to APPLY PTF3 and PTF4.
Customer does not order PTF2 (after all, it's SUPerseded)
rather, customer orders and RECEIVEs PTF3 and PTF4 and says
"APPLY SELECT(PTF3,PTF4)" How is checking for properly
formed SUP in PTF3 done? Does the check recognize that
PTF2 is SUPBY PTF4, and that this means that PTF4 therefore
guarantees equivalent or superior maintenance to PTF2, and
use PTF4 in the checking instead of the unavailable PTF2?
Thanks,
Bruce Hewson
Are you sure the SUP for PTF4 is correct. You have it set to SUP(PTF1) but I
would think since it only update MODA and MODB that it could/should
supercede PTF2.
In your commentry you mention PTF2 being superceded.
Can you advise if my supposition is correct.
> ------------------------------
>
> Date: Wed, 17 Oct 2001 12:40:31 -0600
> From: p...@SWENG.STORTEK.COM
> Subject: Re: SMP/E APARs IR44571/IR46256 (does sup have all elements?)
>
<snip>
> o And a complex but likely scenario:
>
> SYSMOD Elements Dependencies
>
> PTF1 MODA MODB MODC
> PTF2 MODA MODB PRE(PTF1)
> PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
> PTF4 MODA MODB PRE(PTF2,PTF3) SUP(PTF1)
>
> Customer has APPLYed PTF1 and wishes to APPLY PTF3 and PTF4.
> Customer does not order PTF2 (after all, it's SUPerseded)
> rather, customer orders and RECEIVEs PTF3 and PTF4 and says
> "APPLY SELECT(PTF3,PTF4)" How is checking for properly
> formed SUP in PTF3 done? Does the check recognize that
> PTF2 is SUPBY PTF4, and that this means that PTF4 therefore
> guarantees equivalent or superior maintenance to PTF2, and
> use PTF4 in the checking instead of the unavailable PTF2?
>
> Thanks,
> gil
> --
> StorageTek
> INFORMATION made POWERFUL
>
> ------------------------------
Thanks
Bruce Hewson
p...@sweng.stortek.com
> Date: Thu, 18 Oct 2001 03:58:14 -0500
>
> Are you sure the SUP for PTF4 is correct. You have it set to SUP(PTF1) but I
>
> In your commentry you mention PTF2 being superceded.
>
The commentary is as I intended; the example is incorrect. Should be,
as you infer, as below. (If I can get it right. This is an example
of the reason we generate our PREs and SUPs with a program rather than
manually. It required some iteration to get the program correct. :-)
Thanks,
gil
------------------------------
o And a complex but likely scenario:
SYSMOD Elements Dependencies
PTF1 MODA MODB MODC
PTF2 MODA MODB PRE(PTF1)
PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
PTF4 MODA MODB PRE(PTF3) SUP(PTF2,PTF1)
Customer has APPLYed PTF1 and wishes to APPLY PTF3 and PTF4.
Customer does not order PTF2 (after all, it's SUPerseded)
rather, customer orders and RECEIVEs PTF3 and PTF4 and says
"APPLY SELECT(PTF3,PTF4)" How is checking for properly
formed SUP in PTF3 done? Does the check recognize that
PTF2 is SUPBY PTF4, and that this means that PTF4 therefore
guarantees equivalent or superior maintenance to PTF2, and
use PTF4 in the checking instead of the unavailable PTF2?
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Kurt Quackenbush
someone happy. In any case, let me answer your questions:
> o What happens if a PRErequisite sysmod is unavailable and the
> customer has specified BYPASS(PRE)? Does the GIM32501E then
> occur?
You bet the GIM32501E occurs. Because of the missing PRE, the
requisite-set does not contain all necessary elements, which is an
error.
> o Is the definition of "requisite" intended to be transitive?
> I.e. are PRErequisites of PRErequisites etc. examined to the
> end of the chain?
Good question since I did not state it explicitly, but the definition is
absolutely transitive... checking is performed all the way to the end of
the requisite chain.
> o And a complex but likely scenario:
Ummmm... I don't think likely because you've got some problems here,
regardless of element content (probably typos). I think you meant for
PTF4 to SUP PTF2 (as opposed to PTF1), and that means PTF4 cannot also
PRE PTF2 (construction error during RECEIVE). Here is what I think you
meant:
SYSMOD Elements Dependencies
PTF1 MODA MODB MODC
PTF2 MODA MODB PRE(PTF1)
PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
PTF4 MODA MODB PRE(PTF3) SUP(PTF2)
If PTF1 is applied and now you wish to APPLY only PTF3 and PTF4, it
works hunky-dory with no GIM32501E messages. What else you got Gil?
;-)
Kurt Quackenbush -- IBM, SMP/E Development
p...@sweng.stortek.com
> Date: Thu, 18 Oct 2001 11:41:35 -0400
>
> > o What happens if a PRErequisite sysmod is unavailable and the
> > customer has specified BYPASS(PRE)? Does the GIM32501E then
> > occur?
>
> You bet the GIM32501E occurs. Because of the missing PRE, the
> requisite-set does not contain all necessary elements, which is an
> error.
>
I can live with this.
> > o Is the definition of "requisite" intended to be transitive?
> > I.e. are PRErequisites of PRErequisites etc. examined to the
> > end of the chain?
>
> Good question since I did not state it explicitly, but the definition is
> absolutely transitive... checking is performed all the way to the end of
> the requisite chain.
>
I'm elated.
> > o And a complex but likely scenario:
>
> Ummmm... I don't think likely because you've got some problems here,
> regardless of element content (probably typos). I think you meant for
> PTF4 to SUP PTF2 (as opposed to PTF1), and that means PTF4 cannot also
> PRE PTF2 (construction error during RECEIVE). Here is what I think you
> meant:
>
> SYSMOD Elements Dependencies
>
> PTF1 MODA MODB MODC
> PTF2 MODA MODB PRE(PTF1)
> PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
> PTF4 MODA MODB PRE(PTF3) SUP(PTF2)
>
> If PTF1 is applied and now you wish to APPLY only PTF3 and PTF4, it
> works hunky-dory with no GIM32501E messages.
>
I'd expect not. Rather, I'd expect a MODID check on MODA because
MODA has RMID=PTF1 and is replaced by PTF4 which neither SUPs nor
PREs PTF1. What (I think) I meant was:
PTF4 MODA MODB PRE(PTF3) SUP(PTF1,PTF2)
PTF4 SUP(PTF1) rather than PRE because PTF4 with its requisite
PTF3 replaces all the elements of PTF1. But I believe you answered
the crux of my question, which was whether the PTF2 SUP(PTF1)
was free of GIM32501E. (And, no, I wasn't sharp to spot this.
rather I was dull to allow the problem actually to occur because
of an early design error in our dependency generation code,
repaired promptly upon discovery.)
> What else you got Gil?
> ;-)
>
More soon enough, but far enough off this topic to require a
new thread. :-)
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Kurt Quackenbush
SYSMOD Elements Dependencies
PTF1 MODA MODB MODC
PTF2 MODA MODB PRE(PTF1)
PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
PTF4 MODA MODB PRE(PTF3) SUP(PTF1,PTF2)
If PTF1 is applied and now you wish to APPLY only PTF3 and PTF4, it
works hunky-dory with no GIM32501E messages.
Let me know if there are further questions or comments.
Kurt Quackenbush -- IBM, SMP/E Development
----------------------------------------------------------------------
Tom Puddicombe
S(PTF4). or do I have to RESTORE S(PTF3,PTF4).?
Kurt Quackenbush <ku...@US.IBM.COM>@BAMA.UA.EDU> on 10/19/2001 09:54:01 AM
Please respond to IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
Sent by: IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU>
To: IBM-...@BAMA.UA.EDU
cc:
Subject: Re: SMP/E APARs IR44571/IR46256 (does sup have all elements?)
Chase, John
> OK, so I applied PTF3 and PTF4 and PTF4 subsequently goes PE, can I
> RESTORE
> S(PTF4). or do I have to RESTORE S(PTF3,PTF4).?
Neither, because PTF4 contained a ++DELETE for MODZ. ;-)
-jc-
p...@sweng.stortek.com
> Date: Fri, 19 Oct 2001 11:31:34 -0400
>
> OK, so I applied PTF3 and PTF4 and PTF4 subsequently goes PE, can I RESTORE
> S(PTF4). or do I have to RESTORE S(PTF3,PTF4).?
>
>
> Kurt Quackenbush <ku...@US.IBM.COM>@BAMA.UA.EDU> on 10/19/2001 09:54:01 AM
>
> OK, after all the corrections, here is the test case:
>
> SYSMOD Elements Dependencies
> PTF1 MODA MODB MODC
> PTF2 MODA MODB PRE(PTF1)
> PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
> PTF4 MODA MODB PRE(PTF3) SUP(PTF1,PTF2)
>
> If PTF1 is applied and now you wish to APPLY only PTF3 and PTF4, it
> works hunky-dory with no GIM32501E messages.
>
I think this is a good question. The answer should be independent
of APARs IR44571, IR46256, and IR44571. Simply, the RESTORE SELECT(PTF4)
should fail because it creates a situation in which PTF3 is missing
PRErequisite PTF2. I don't know what actually happens. This might
be even worse if you've ACCEPTed PTF3 -- in the Bad Old Days this would
leave you completely stymied -- you wouldn't have the PTF1 versions of
MODB and MODC in the DLIB to do the RESTORE. Nowadays, the Improved
Load Module Build Facility will fetch required versions of MOD elements
from the SMPPTS if they are unavailable in the DLIB. Does this mean
it's now permissible to RESTORE a PTF that's already been ACCEPTed?
This brings to mind a related question: Since the advent of Improved
Load Module Build Facility, will ACCEPT fetch all element types
(e.g. MAC) from SMPPTS if they can't be got from DLIB; or is this
limited, as the name suggests, to MOD elements?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Kurt Quackenbush
>
> In a recent note, Tom Puddicombe said:
>
> > Date: Fri, 19 Oct 2001 11:31:34 -0400
> >
> > OK, so I applied PTF3 and PTF4 and PTF4 subsequently goes PE, can I RESTORE
> > S(PTF4). or do I have to RESTORE S(PTF3,PTF4).?
> >
> >
> > Kurt Quackenbush <ku...@US.IBM.COM>@BAMA.UA.EDU> on 10/19/2001 09:54:01 AM
> >
> > OK, after all the corrections, here is the test case:
> >
> > SYSMOD Elements Dependencies
> > PTF1 MODA MODB MODC
> > PTF2 MODA MODB PRE(PTF1)
> > PTF3 MODB MODC PRE(PTF2) SUP(PTF1)
> > PTF4 MODA MODB PRE(PTF3) SUP(PTF1,PTF2)
> >
> > If PTF1 is applied and now you wish to APPLY only PTF3 and PTF4, it
> > works hunky-dory with no GIM32501E messages.
> >
> I think this is a good question. The answer should be independent
> of APARs IR44571, IR46256, and IR44571. Simply, the RESTORE SELECT(PTF4)
> should fail because it creates a situation in which PTF3 is missing
> PRErequisite PTF2.
Absolutely correct. The answer is independent of the subject APARs and
the RESTORE would fail for the missing PRE of PTF2.
> This might
> be even worse if you've ACCEPTed PTF3 -- in the Bad Old Days this would
> leave you completely stymied -- you wouldn't have the PTF1 versions of
> MODB and MODC in the DLIB to do the RESTORE.
Actually in this case you can't accept PTF3 without also accepting
PTF4. The reason is PTF3 PREs PTF2, but PTF2 is superseded by PTF4 in
the target zone, therefore PTF4 must be accepted along with PTF3 to
satisify the PRE for PTF2.
> Nowadays, the Improved
> Load Module Build Facility will fetch required versions of MOD elements
> from the SMPPTS if they are unavailable in the DLIB. Does this mean
> it's now permissible to RESTORE a PTF that's already been ACCEPTed?
No, you still can not RESTORE something that has been accepted. By the
way, the Load Module Build function only applies to APPLY, not to
RESTORE.
> This brings to mind a related question: Since the advent of Improved
> Load Module Build Facility, will ACCEPT fetch all element types
> (e.g. MAC) from SMPPTS if they can't be got from DLIB; or is this
> limited, as the name suggests, to MOD elements?
I think you are asking will "APPLY" fetch all element types from the
SMPPTS. The answer is no... the Load Module Build function does just as
it states: builds load modules.
Kurt Quackenbush -- IBM, SMP/E Development
----------------------------------------------------------------------
p...@sweng.stortek.com
> Date: Mon, 22 Oct 2001 10:25:16 -0400
>
> Absolutely correct. The answer is independent of the subject APARs and
> the RESTORE would fail for the missing PRE of PTF2.
>
Good.
> Actually in this case you can't accept PTF3 without also accepting
> PTF4. The reason is PTF3 PREs PTF2, but PTF2 is superseded by PTF4 in
> the target zone, therefore PTF4 must be accepted along with PTF3 to
> satisify the PRE for PTF2.
>
I understand.
> > Nowadays, the Improved
> > Load Module Build Facility will fetch required versions of MOD elements
> > from the SMPPTS if they are unavailable in the DLIB. Does this mean
> > it's now permissible to RESTORE a PTF that's already been ACCEPTed?
>
> No, you still can not RESTORE something that has been accepted. By the
This is puzzling. I believe there is a maintenance process that
involves ACCEPT prior to APPLY (at least ISPF Panel GIMISPRE appears
to provide such an option:
. 5 ACCEPT/APPLY - ACCEPT followed by APPLY .
... ) If this is so, then it's legal for a SYSMOD to be in a state
where it's ACCEPTed but not APPLYed. Why shouldn't it be permitted
to enter this state by RESTORE after ACCEPT and APPLY, as well as by
ACCEPT before APPLY?
> way, the Load Module Build function only applies to APPLY, not to
> RESTORE.
>
This is a disappointment. I had belived that the chief benefit of
this function would be to permit customers to RESTORE a given SYSMOD
without the need to ACCEPT all its prerequisites. As it is, it
appears to provide only the very limited benefit of allowing new
load modules to built using MOD elements that have been APPLYed
but not ACCEPTed, and which do not exist solo in any target library.
Have I overlooked any other benefit?
> > This brings to mind a related question: Since the advent of Improved
> > Load Module Build Facility, will ACCEPT fetch all element types
> > (e.g. MAC) from SMPPTS if they can't be got from DLIB; or is this
> > limited, as the name suggests, to MOD elements?
>
> I think you are asking will "APPLY" fetch all element types from the
You understand correctly.
> SMPPTS. The answer is no... the Load Module Build function does just as
> it states: builds load modules.
>
Why not? Again, it would seem of greater benefit to have provided the
more general implementation. If you're going to do it for one element
type, why not for all?
Thanks,
gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Kurt Quackenbush
>
> involves ACCEPT prior to APPLY (at least ISPF Panel GIMISPRE appears
> to provide such an option:
> . 5 ACCEPT/APPLY - ACCEPT followed by APPLY .
> where it's ACCEPTed but not APPLYed.
Yes, it is legal for something to be accepted but not applied, but the
ACCEPT/APPLY path is somewhat analogous to the ACCEPT/sysgen path, which
I'm fairly certain is not the mainstream. I can think of very few
instances where I would recommend this path.
> Why shouldn't it be permitted
> to enter this state by RESTORE after ACCEPT and APPLY, as well as by
> ACCEPT before APPLY?
Because that is not what RESTORE does. As designed and implemented,
RESTORE's function is to un-do whatever happened during APPLY and to
bring the target libraries back to an "accepted" service level, which by
definition is the the level found in the distribution libraries. I
think I understand what you are asking for, but that is not what RESTORE
does.
> > the Load Module Build function only applies to APPLY, not to RESTORE.
> >
> This is a disappointment. I had belived that the chief benefit of
> this function would be to permit customers to RESTORE a given SYSMOD
> without the need to ACCEPT all its prerequisites. As it is, it
> appears to provide only the very limited benefit of allowing new
> load modules to built using MOD elements that have been APPLYed
> but not ACCEPTed, and which do not exist solo in any target library.
> Have I overlooked any other benefit?
No, you've captured the benefit accurately. Limited? Perhaps, but
building load modules and not including all mods was a problem which
this function fixed.
> > > This brings to mind a related question: Since the advent of Improved
> > > Load Module Build Facility, will ACCEPT fetch all element types
> > > (e.g. MAC) from SMPPTS if they can't be got from DLIB; or is this
> > > limited, as the name suggests, to MOD elements?
> >
> > I think you are asking will "APPLY" fetch all element types from the
>
> You understand correctly.
>
> > SMPPTS. The answer is no... the Load Module Build function does just as
> > it states: builds load modules.
> >
> Why not? Again, it would seem of greater benefit to have provided the
> more general implementation. If you're going to do it for one element
> type, why not for all?
If we had intended to re-architect RESTORE, then I can see where
fetching all element types from the SMPPTS would be meaningful.
However, this was not the intent, and I don't see a need to handle other
element types for APPLY.
Kurt Quackenbush -- IBM, SMP/E Development
----------------------------------------------------------------------