Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-27 Thread Shmuel Metz (Seymour J.)
In <2898629948738139.wa.paulgboulderaim@listserv.ua.edu>, on 09/26/2012 at 08:56 AM, Paul Gilmartin said: >I stand corrected. But still, if RECEIVE tolerates processing a >SYSMOD prior to its PRErequisites on the assumption that APPLY >will sort things out, I might hope for the same flex

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-27 Thread Kurt Quackenbush
Why does order matter? Is it because the FMID list in the GZONE entry is not updated until RECEIVE processing for that SYSMOD is complete, only after which it moves on to the next? That is exactly correct. Kurt Quackenbush -- IBM, SMP/E Development

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-26 Thread Paul Gilmartin
On Wed, 26 Sep 2012 10:47:09 -0500, Art Gutowski wrote: > >>RECEIVE SELECT( >>F1 >>F2 >>F3 >>) FROMNTS(SMPNTS-path) > >Was this a typo or intentional? The rest of what follows lists E2 and E3, >which I am surprised RECEIVE would process since these are not part of the >SELECT

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-26 Thread Art Gutowski
On Wed, 26 Sep 2012 08:56:21 -0500, Paul Gilmartin wrote: >But still, if RECEIVE tolerates processing a SYSMOD prior to its PRErequisites >on the assumption that >APPLY will sort things out, I might hope for the same flexibility with respect >to FMID. RECEIVE doesn't so much "tolerate" as it ig

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-26 Thread Paul Gilmartin
On Wed, 26 Sep 2012 08:32:02 -0500, Art Gutowski wrote: > >>Perhaps even more relevant is the ordering among PREs and SUPs of PTFs, >>where order of SYSMODs in SMPPTFIN under a single APPLY command doesn't >>matter. > >SMPPTFIN is not read during APPLY. That would be SMPPTS. PREs and SUPs don't

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-26 Thread Art Gutowski
On Tue, 25 Sep 2012 17:42:12 -0500, Paul Gilmartin wrote: >Perhaps even more relevant is the ordering among PREs and SUPs of PTFs, >where order of SYSMODs in SMPPTFIN under a single APPLY command doesn't >matter. SMPPTFIN is not read during APPLY. That would be SMPPTS. PREs and SUPs don't mat

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-25 Thread Paul Gilmartin
On Tue, 25 Sep 2012 17:24:32 -0500, Art Gutowski wrote: >On Mon, 24 Sep 2012 09:18:09 -0400, Kurt Quackenbush wrote: >>Presumably the MCS for each SYSMOD is in a unique data set? If so, then >>yes, the order in which the archives for those data sets appear in the >>GIMPAF.XML file determines the

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-25 Thread Art Gutowski
On Mon, 24 Sep 2012 09:18:09 -0400, Kurt Quackenbush wrote: >Presumably the MCS for each SYSMOD is in a unique data set? If so, then >yes, the order in which the archives for those data sets appear in the >GIMPAF.XML file determines the order in which they will be processed >during the RECEIVE.

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-24 Thread Kurt Quackenbush
Grrr. What determines the order of processing? OK. I think I have it. They appear to be processed in GIMPAF order. Presumably the MCS for each SYSMOD is in a unique data set? If so, then yes, the order in which the archives for those data sets appear in the GIMPAF.XML file determines

Re: GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-20 Thread Paul Gilmartin
On Thu, 20 Sep 2012 20:20:21 -0500, Paul Gilmartin wrote: >I have (schematically) in SMPCNTL: > >RECEIVE SELECT( >F1 >E2 /* Renamed from OP. */ >E3 /* Renamed from OP. */ >) FROMNTS(SMPNTS-path) > >And, variously in SMPNTS: >++ FUNCTION( F1 ) ... > >++ FUNCTION( E2

GIM39001E in SMP/E RECEIVE FROMNTS

2012-09-20 Thread Paul Gilmartin
I have (schematically) in SMPCNTL: RECEIVE SELECT( F1 F2 F3 ) FROMNTS(SMPNTS-path) And, variously in SMPNTS: ++ FUNCTION( F1 ) ... ++ FUNCTION( E2 ) ... ++ VER ... FMID( F1 ) ... ++ FUNCTION( E3 ) ... ++ VER ... FMID( F1 ) ... And I get, in SMPOUT: