Re: SMP/E - module attributes issue
Paul Gilmartin wrote: In a recent note, Tony Harminc said: Date: Tue, 14 Nov 2006 18:25:40 -0500 On Thu 9 November, 2006 Paul Gilmartin wrote: Ugh. How do you package a LMOD in a PTF? Inline with GIMDTS? (Doesn't work.) Better with FROMNETWORK, which is relfile-friendly, even in PTFs. (I know; it's theoretically possible to RELFILE-package a PTF, but customers don't expect it.) I'm curious; what doesn't work about an LMOD done inline with GIMDTS? IIRC (it's fuzzy; subject to verification) several things: o LMOD is not a deliverable element type. snip From the SMP/E Reference: The ++PROGRAM MCS describes a program element (a pre-built load module or a program object). -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- 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
Re: SMP/E - module attributes issue
In a recent note, John Eells said: Date: Wed, 15 Nov 2006 08:35:43 -0500 From the SMP/E Reference: The ++PROGRAM MCS describes a program element (a pre-built load module or a program object). I had forgotten about that; thanks. (I tend to forget things I don't regularly use.) Of course, if the OP is trying to recreate the former structure of the CSI, changing ++MOD to ++PROGRAM may be unwelcome. OK. From the RM: Usage Notes * The target and distribution libraries for a program element must be a PDS (for pre-built load module) or a PDSE (for a program object). ... During the APPLY step, SMP/E retransforms the inline data back into a variable spanned (VS) sequential data set. SMP/E then invokes the copy utility to copy the retransformed data into the target library. The program element and aliases are copied using a COPYMOD and SELECT statements. Won't COPYMOD convert load modules to program objects, slightly relaxing the restriction? * If the program element is packaged inline, it must immediately follow the ++PROGRAM MCS and must not contain any records starting with ++. ... * To be packaged inline, a program element must be unloaded along with its aliases into a sequential data set and then transformed into the required fixed-block-80 record format ... [implied in the example, but not otherwise stated, that GIMDTS is the necessary transforming utility.] Doesn't using GIMDTS, apparently a requirement, automatically satisfy the constraint on ++, and make it unnecessary to state? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: SMP/E - module attributes issue
On Mon, 13 Nov 2006 11:21:22 -0500, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: ... So I changed all RELFILE references to TXLIB references, added TXLIB DD statements to the APPLY JCL, and proceeded with the RECEIVE and APPLY. ... Why? If you had already done a RECEIVE then the proper thing to do was an APPLY CHECK, not another RECEIVE, and certainly not a RECEIVE with modified MCS. ... You apparently missed the part about a completely separate SMP environment. Completely: different CSI including the GLOBAL zone and PTS. It's use that or wait another 3 or 4 months until the MVS folks are ready to do the APPLY. And no, they aren't willing to give me a couple new, empty zones attached to their global zone. Within half a year the MVS folks will have installed the product. Within a few weeks a newly ordered copy of the tapes should arrive for me to do my own clean install. And I have a completely empty set of SMP datasets that I can scratch and reallocate at any time. I saw, and still see, no downside. This looks like the perfect chance reacquaint myself with SMP, and to try something out of the ordinary, but really pretty simple. but I don't understand how this happened. It happened because you changed things that you didn't understand. In this case it was crucial to distinguish between object libraries and load libraries. I won't say never edit the MCS of a function, but when you must do so, do it with fear and trembling. Actually (perhaps givig myself more credit than I deserve) I'd say it was not understanding how SMP treats object vs. load libraries rather than not understanding the difference between the libraries. And I admit that I had forgotten that there even was an LKLIB specification. I definitely need some SMP practice and this looks like the perfect chance. Pat O'Keefe -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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 = -- 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
Re: SMP/E - module attributes issue
On Thu 9 November, 2006 Paul Gilmartin wrote: Ugh. How do you package a LMOD in a PTF? Inline with GIMDTS? (Doesn't work.) Better with FROMNETWORK, which is relfile-friendly, even in PTFs. (I know; it's theoretically possible to RELFILE-package a PTF, but customers don't expect it.) I'm curious; what doesn't work about an LMOD done inline with GIMDTS? Tony H. -- 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
Re: SMP/E - module attributes issue
In a recent note, Tony Harminc said: Date: Tue, 14 Nov 2006 18:25:40 -0500 On Thu 9 November, 2006 Paul Gilmartin wrote: Ugh. How do you package a LMOD in a PTF? Inline with GIMDTS? (Doesn't work.) Better with FROMNETWORK, which is relfile-friendly, even in PTFs. (I know; it's theoretically possible to RELFILE-package a PTF, but customers don't expect it.) I'm curious; what doesn't work about an LMOD done inline with GIMDTS? IIRC (it's fuzzy; subject to verification) several things: o LMOD is not a deliverable element type. o GIMDTS is permitted only for data elements; not for the classic MOD, MAC, SRC, etc. (Why?!) o Come to think of it, the directory information would still not be preserved. o An inline MOD element is expected to be in SYSLIN format, not a load module. Don't you just love MVS? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: SMP/E - module attributes issue
Seems to me that ++PROGRAM relieves at least some of these limitations. Brian On Tue, 14 Nov 2006 17:58:02 -0700, Paul Gilmartin wrote: IIRC (it's fuzzy; subject to verification) several things: o LMOD is not a deliverable element type. o GIMDTS is permitted only for data elements; not for the classic MOD, MAC, SRC, etc. (Why?!) o Come to think of it, the directory information would still not be preserved. o An inline MOD element is expected to be in SYSLIN format, not a load module. Don't you just love MVS? -- gil -- 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
Re: SMP/E - module attributes issue
In [EMAIL PROTECTED], on 11/09/2006 at 12:00 PM, Patrick O'Keefe [EMAIL PROTECTED] said: Ok. No tapes, but all the MCS statements were in the system PTS, all the RELFILE files had built their PDSs, etc. All the data was there. So I changed all RELFILE references to TXLIB references, added TXLIB DD statements to the APPLY JCL, and proceeded with the RECEIVE and APPLY. Why? If you had already done a RECEIVE then the proper thing to do was an APPLY CHECK, not another RECEIVE, and certainly not a RECEIVE with modified MCS. It would have better to reorder the tapes and in the meantime find out why the old tapes were thrown out and to ensure that it didn't happen again. but I don't understand how this happened. It happened because you changed things that you didn't understand. In this case it was crucial to distinguish between object libraries and load libraries. I won't say never edit the MCS of a function, but when you must do so, do it with fear and trembling. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: SMP/E - module attributes issue
Shmuel, Too bad you missed most of this thread. Your suggestion for APPLY CHECK did not apply in this case. And Patrick did and does understand this stuff quite well. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, November 13, 2006 11:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMP/E - module attributes issue In [EMAIL PROTECTED], on 11/09/2006 at 12:00 PM, Patrick O'Keefe [EMAIL PROTECTED] said: Ok. No tapes, but all the MCS statements were in the system PTS, all the RELFILE files had built their PDSs, etc. All the data was there. So I changed all RELFILE references to TXLIB references, added TXLIB DD statements to the APPLY JCL, and proceeded with the RECEIVE and APPLY. Why? If you had already done a RECEIVE then the proper thing to do was an APPLY CHECK, not another RECEIVE, and certainly not a RECEIVE with modified MCS. It would have better to reorder the tapes and in the meantime find out why the old tapes were thrown out and to ensure that it didn't happen again. but I don't understand how this happened. It happened because you changed things that you didn't understand. In this case it was crucial to distinguish between object libraries and load libraries. I won't say never edit the MCS of a function, but when you must do so, do it with fear and trembling. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: SMP/E - module attributes issue
There must be some sort of subtle difference between object modules located in RELFILEs versus object modules located in TXLIBs. Brian is onto it here. For MODs, packaging using TXLIB and inline (as in a typical PTF) tells SMP/E the module is supplied as an object deck that requires a link edit operation. SMP/E doesn't analyze the TXLIB, so it makes no difference whether the TXLIB data set truly contains an FB-80 object deck or if it contains a RECFM=U load module as in your case; SMP/E will invoke the binder for MODs supplied by TXLIB. Packaging using RELFILE, LKLIB, and FROMDS tells SMP/E the module is supplied in load module form and can be copied. LKLIB would have been your best bet. Also, the way I think about JCLIN is that JCLIN describes a product's *structure*, it does NOT describe a product's installation process. An excellent point that can always use repeating. JCLIN is not executed and does not determine the utility to use for installation. SMP/E reads JCLIN to determine load module contents, attributes, destination, etc. and it is the element packaging that determines the utility. Kurt Quackenbush -- IBM, SMP/E Development -- 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
Re: SMP/E - module attributes issue
On Fri, 10 Nov 2006 09:50:07 -0500, Kurt Quackenbush [EMAIL PROTECTED] wrote: ... For MODs, packaging using TXLIB and inline (as in a typical PTF) tells SMP/E the module is supplied as an object deck that requires a link edit operation. SMP/E doesn't analyze the TXLIB, so it makes no difference whether the TXLIB data set truly contains an FB-80 object deck or if it contains a RECFM=U load module as in your case; SMP/E will invoke the binder for MODs supplied by TXLIB. Packaging using RELFILE, LKLIB, and FROMDS tells SMP/E the module is supplied in load module form and can be copied. LKLIB would have been your best bet. ... It sounds like I was just lucky for most of this. The JCLIN had BINDER steps for all but 2 modules so all but 2 of those links were actually called for. However, ACCEPT, which should be doing copies, also wants to do a link for every module in those linklibs. I'm toast. I either start over from scratch or wait for the newly reordered product tapes. Or I can do a massive UCLIN to change the TXLIB to LKLIB on all MOD elements in those linklibs. Than sounds like an enjoyable task. :-) Pat O'Keefe -- 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
Re: SMP/E - module attributes issue
On Fri, 2006-11-10 at 10:36 -0600, Patrick O'Keefe wrote: I'm toast. I either start over from scratch or wait for the newly reordered product tapes. Or I can do a massive UCLIN to change the TXLIB to LKLIB on all MOD elements in those linklibs. Than sounds like an enjoyable task. :-) BUILDMCS ???. Shane ... -- 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
Re: SMP/E - module attributes issue
Pat, I forget where you started with this but could you have used the BUILDMCS function to get all your stuff out of the old CSI and populate the new one? Patrick O'Keefe [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 11/10/2006 10:36 Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: SMP/E - module attributes issue On Fri, 10 Nov 2006 09:50:07 -0500, Kurt Quackenbush [EMAIL PROTECTED] wrote: ... For MODs, packaging using TXLIB and inline (as in a typical PTF) tells SMP/E the module is supplied as an object deck that requires a link edit operation. SMP/E doesn't analyze the TXLIB, so it makes no difference whether the TXLIB data set truly contains an FB-80 object deck or if it contains a RECFM=U load module as in your case; SMP/E will invoke the binder for MODs supplied by TXLIB. Packaging using RELFILE, LKLIB, and FROMDS tells SMP/E the module is supplied in load module form and can be copied. LKLIB would have been your best bet. ... It sounds like I was just lucky for most of this. The JCLIN had BINDER steps for all but 2 modules so all but 2 of those links were actually called for. However, ACCEPT, which should be doing copies, also wants to do a link for every module in those linklibs. I'm toast. I either start over from scratch or wait for the newly reordered product tapes. Or I can do a massive UCLIN to change the TXLIB to LKLIB on all MOD elements in those linklibs. Than sounds like an enjoyable task. :-) Pat O'Keefe -- 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
Re: SMP/E - module attributes issue
Nope. The starting point for this little adventure was FMIDs RECEIVEd but not applied or accepted. Bria On Sat, 11 Nov 2006 02:41:07 +1000, Shane [EMAIL PROTECTED] wrote: On Fri, 2006-11-10 at 10:36 -0600, Patrick O'Keefe wrote: I'm toast. I either start over from scratch or wait for the newly reordered product tapes. Or I can do a massive UCLIN to change the TXLIB to LKLIB on all MOD elements in those linklibs. Than sounds like an enjoyable task. :-) BUILDMCS ???. Shane ... -- 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
Re: SMP/E - module attributes issue
On Fri, 10 Nov 2006 10:53:43 -0600, Brian Peterson [EMAIL PROTECTED] wrote: Nope. The starting point for this little adventure was FMIDs RECEIVEd but ... BUILDMCS ???. ... Actually, I could do a BUILDMCS now and see what I get, but since I had the wrong thing (TXLIB instead of LKLIB) on the original MCS statements I don't think I would get any better MCS statements out of the BUILDMCS. This is all just an educational experience now since I'll start from scratch when the reordered tapes show up. I think I'll try a BUILDMSC just to see what I get, but I don't expect anything useful. Pat O'Keefe -- 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
Re: SMP/E - module attributes issue
On Fri, 10 Nov 2006 11:12:23 -0600, Patrick O'Keefe [EMAIL PROTECTED] wrote: On Fri, 10 Nov 2006 10:53:43 -0600, Brian Peterson [EMAIL PROTECTED] wrote: Nope. The starting point for this little adventure was FMIDs RECEIVEd but ... BUILDMCS ???. ... Actually, I could do a BUILDMCS now and see what I get, but since I had the wrong thing (TXLIB instead of LKLIB) on the original MCS statements I don't think I would get any better MCS statements out of the BUILDMCS. You could clone your MVS global zone if you really think you must keep NetView in a different global. Then you could strip that global zone down to what you need. I would argue that cloning the target and dlib would provide sufficient isolation, as someone else pointed out. -- Tom Marchant -- 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
Re: SMP/E - module attributes issue
Talk about doing things the hard way!! Here's some ideas you might consider. You probably already thought of them - if so, sorry! 1) Order a new copy of the product. Perform your own RECEIVE from the original copy of the product. This is the start from scratch option. 2) Define new Target and DLIB SMP/E CSI and Target and DLIB data sets. Attach this new, empty, Target and DLIB zone to the Global zone which has the product RECEIVEd into. Perform the APPLY and ACCEPT into the new Target and DLIB zones - this won't affect the MVS zones at all. Detatch the Target and DLIB zones from the existing Global, and attach them to a new, empty, Global. Update the FMIDLIST in the new Global to reflect the FMIDs you've got in your Target zone, so that subsequent RECEIVE processing will get service applicable to your FMIDs. This is the start from here option. The only objection I can imagine to option 2 would be religious, not rational, on the part of the MVS sysprogs. I wouldn't attempt to reengineer the product's packaging in the way you apparently attempted. Life's too short! Brian On Thu, 9 Nov 2006 12:00:20 -0600, Patrick O'Keefe wrote: I think I may have abused SMP and it has retaliated. Help would be appreciated. 7 or 8 months ago our MVS team received a new release of NetView into our main MVS SMP environment. They then decided they were too busy to do anything with it. Last week I was givin permission to do the install but I had to do it in its own SMP environment - it's own CSI, SMP datasets, target and dlib datasets, etc. And by the way, the installation tapes were thrown away. Ok. No tapes, but all the MCS statements were in the system PTS, all the RELFILE files had built their PDSs, etc. All the data was there. So I changed all RELFILE references to TXLIB references, added TXLIB DD statements to the APPLY JCL, and proceeded with the RECEIVE and APPLY. Only 2 modules out of thousands had a problem. They generated the message GIM24701W SMP/E COULD NOT OBTAIN LINK-EDIT PARAMETERS FOR LOAD MODULE xxx FOR SYSMOD HENV520. DEFAULTS WERE USED. And those defaults did not include RENT and REUS. These modules were linked into a subroutine library. They were also included in a couple modules in the product's main linklib. Those latter 2 modules were correctly linked with RENT and REUS. During JCLIN processing the 2 modules in error were flagged with the message COPY INDICATOR SET. No other modules got this, so I suspect that is related. I know I can relink the modules in the subroutine library (or just copy them from their TXLIB PDS) to get the RENT and REUS attributes back so I'm not terribly worried, but I don't understand how this happened. Does anyone have an explanation? Thanks in advance. Pat O'Keefe -- 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 = -- 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
Re: SMP/E - module attributes issue
On Thu, 9 Nov 2006 12:24:22 -0600, Brian Peterson [EMAIL PROTECTED] wrote: Talk about doing things the hard way!! Here's some ideas you might consider. You probably already thought of them - if so, sorry! ... One person's hard is another's fun. I haven't had a hands-on fight with SMP for several years and am really enjoying this. (Yup. I'm sick!) This is the way I learn. ... 1) Order a new copy of the product. Perform your own RECEIVE from the original copy of the product. This is the start from scratch option. Parallel channel. Our contract people were already chewing on this, trying to make sure we wouldn't be ordering a new license. As I was writing this I got word that the order has gone in. (I guess I'm glad.) But I still want to know what went wrong here. ... 2) Define new Target and DLIB SMP/E CSI and Target and DLIB data sets. Attach this new, empty, Target and DLIB zone to the Global zone which has the product RECEIVEd into. ... The only objection I can imagine to option 2 would be religious, not rational, on the part of the MVS sysprogs. Religious and political. That is a very rational solution, and would work well. I''l suggest it, but I suspect I know the response. ... I wouldn't attempt to reengineer the product's packaging in the way you apparently attempted. Life's too short! As you can tell from my comments above, I look at this differently. The fact that I ran into this problem tells me I don't understand SMP (as if that surprises anybody!). The fact that only 2 modules had problems says either I had a reasonable grasp on what I was doing or I was VERY lucky. More of the later than the former, I fear. A little more digging, very obvious digging that I should have done right off the bat, showed me part of what was wrong ... and uncovered a glaring hole in my understanding of SMP. I looked at the JCLIN (duh!) and saw /* // //** STEP 15** //**** //** MVS utility IEBCOPY will be used to COPY these two LMODs ** //** from the installation tape into a Target Library. ** //** These LMODs don't LINKEDIT well, and need to be copied ** //** to ensure an overall return code of 00 for SMP/E ** //** installation processing on this FMID. ** //**** //** TARGLIB - SYS1.NVULIB ** //** DISTLIB - SYS1.ANVULIB ** // //STEP15 EXEC PGM=IEBCOPY //SYSPRINT DD SYSOUT=A //NVULIB DD DSN=SYS1.NVULIB,DISP=SHR //ANVULIB DD DSN=SYS1.ANVULIB,DISP=SHR //SYSIN DD * COPY INDD=ANVULIB,OUTDD=NVULIB SELECT M=CNMVLC SELECT M=CNMNVLC /* So why did SMP link it? Obviously it couldn't do the copy in the JCLIN because there's noting in the DLIB until ACCEPT, but why didn't it copy from the TXLIB. It obviously found the module in the TXLIB because that's what it linked. Previous steps in the JCLIN had specified linking into NVULIB. Does that make SMP always link into that library, regardless what later JCLIN says? Pat O'Keefe -- 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
Re: SMP/E - module attributes issue
In a recent note, Patrick O'Keefe said: Date: Thu, 9 Nov 2006 16:30:46 -0600 2) Define new Target and DLIB SMP/E CSI and Target and DLIB data sets. Attach this new, empty, Target and DLIB zone to the Global zone which has the product RECEIVEd into. ... Religious and political. That is a very rational solution, and would work well. I''l suggest it, but I suspect I know the response. I thought SMP/E has considerable facilities for copying a CSI with internal renaming. But I've never used them. A little more digging, very obvious digging that I should have done right off the bat, showed me part of what was wrong ... and uncovered a glaring hole in my understanding of SMP. I looked at the JCLIN (duh!) and saw // //** MVS utility IEBCOPY will be used to COPY these two LMODs ** //** from the installation tape into a Target Library. ** //** These LMODs don't LINKEDIT well, and need to be copied ** //** to ensure an overall return code of 00 for SMP/E ** //** installation processing on this FMID. ** // The Garden of Eden state. I wonder how the Creator built them. I wonder what happens if they ever need service. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: SMP/E - module attributes issue
I admire your determination! Keep it up - that's what keeps all of us young at heart! As far as why you're getting a link edit operation doing things Pat's way, I suspect the answer has to do with the complex process SMP/E uses to build load modules - a process which has been enhanced over the years. There must be some sort of subtle difference between object modules located in RELFILEs versus object modules located in TXLIBs. Check out Appendix C Building load modules in publication SMP/E for z/OS Commands. Also, the way I think about JCLIN is that JCLIN describes a product's *structure*, it does NOT describe a product's installation process. Brian On Thu, 9 Nov 2006 16:30:46 -0600, Patrick O'Keefe wrote: On Thu, 9 Nov 2006 12:24:22 -0600, Brian Peterson wrote: Talk about doing things the hard way!! Here's some ideas you might consider. You probably already thought of them - if so, sorry! ... One person's hard is another's fun. I haven't had a hands-on fight with SMP for several years and am really enjoying this. (Yup. I'm sick!) This is the way I learn. (snip) As you can tell from my comments above, I look at this differently. The fact that I ran into this problem tells me I don't understand SMP (as if that surprises anybody!). The fact that only 2 modules had problems says either I had a reasonable grasp on what I was doing or I was VERY lucky. More of the later than the former, I fear. A little more digging, very obvious digging that I should have done right off the bat, showed me part of what was wrong ... and uncovered a glaring hole in my understanding of SMP. I looked at the JCLIN (duh!) and saw /* // //** STEP 15** //**** //** MVS utility IEBCOPY will be used to COPY these two LMODs ** //** from the installation tape into a Target Library. ** //** These LMODs don't LINKEDIT well, and need to be copied ** //** to ensure an overall return code of 00 for SMP/E ** //** installation processing on this FMID. ** //**** //** TARGLIB - SYS1.NVULIB ** //** DISTLIB - SYS1.ANVULIB ** // //STEP15 EXEC PGM=IEBCOPY //SYSPRINT DD SYSOUT=A //NVULIB DD DSN=SYS1.NVULIB,DISP=SHR //ANVULIB DD DSN=SYS1.ANVULIB,DISP=SHR //SYSIN DD * COPY INDD=ANVULIB,OUTDD=NVULIB SELECT M=CNMVLC SELECT M=CNMNVLC /* So why did SMP link it? Obviously it couldn't do the copy in the JCLIN because there's noting in the DLIB until ACCEPT, but why didn't it copy from the TXLIB. It obviously found the module in the TXLIB because that's what it linked. Previous steps in the JCLIN had specified linking into NVULIB. Does that make SMP always link into that library, regardless what later JCLIN says? Pat O'Keefe -- 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
Re: SMP/E - module attributes issue
On Thu, 9 Nov 2006 17:00:53 -0600, Brian Peterson [EMAIL PROTECTED] wrote: ... Also, the way I think about JCLIN is that JCLIN describes a product's *structure*, it does NOT describe a product's installation process. ... In general, you're right, but SMP processes JCLIN for link steps to get library references, linkedit options, etc. It can obviously get dataset info from an IEBCOPY step, but cannot (as it admitted) determine linkedit parms from an IEBCOPY step. So why did it try to do a LINK? Yes, yes, I know. RTFM. Ok. I will. Pat O'Keefe -- 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
Re: SMP/E - module attributes issue
On Thu, 9 Nov 2006 15:48:00 -0700, Paul Gilmartin [EMAIL PROTECTED] wrote: ... // //** MVS utility IEBCOPY will be used to COPY these two LMODs ** //** from the installation tape into a Target Library. ** //** These LMODs don't LINKEDIT well, and need to be copied ** //** to ensure an overall return code of 00 for SMP/E ** //** installation processing on this FMID. ** // The Garden of Eden state. I wonder how the Creator built them. I wonder what happens if they ever need service. ... I bet there's an interesting story there that will probably stay untold. Obviously, someone linked it once. And SMP linked for me without problem. It's not SMP's fault that it didn't know that appropriate attributes since it wasn't given any. If it ever needs service IBM will probably rebuild it in some mysterious way and then provide a replacement LMOD to be IEBCOPYed into the library. Pat O'Keefe -- 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
Re: SMP/E - module attributes issue
In a recent note, Patrick O'Keefe said: Date: Thu, 9 Nov 2006 17:58:04 -0600 I wonder how the Creator built them. I wonder what happens if they ever need service. I bet there's an interesting story there that will probably stay untold. Obviously, someone linked it once. And SMP linked for me without problem. It's not SMP's fault that it didn't know that appropriate attributes since it wasn't given any. A couple possibilities: o the developer/packager didn't know how to code a link edit step. o The build requires a prelinker. SMP/E doesn't agree with prelinkers. If it ever needs service IBM will probably rebuild it in some mysterious way and then provide a replacement LMOD to be IEBCOPYed into the library. Ugh. How do you package a LMOD in a PTF? Inline with GIMDTS? (Doesn't work.) Better with FROMNETWORK, which is relfile-friendly, even in PTFs. (I know; it's theoretically possible to RELFILE-package a PTF, but customers don't expect it.) --gil -- StorageTek INFORMATION made POWERFUL -- 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
