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 > xxxxxxx 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
