As already pointed out, DDDEFs are not owned by FMIDs, components, or even products. The association to a particular DDDEF is defined for each element that needs a home. So the SYSLIB entry for LMOD AMATERSE points to MIGLIB, while the PNLENU entry for ISR@PRIM points to SISPPENU.
OP did not supply a business case for splitting out 'shared' components from 'unique' ones, but I suspect that DASD usage and management must be a concern. My advice: don't do it. z/OS is not packaged for this kind of after-market segregation. After much research and cogitation, you may come up with a 'safe list' of things to banish to the north forty. Even if you get it right today, it could fall apart tomorrow with a PTF, let alone a new release. And if you split zones, how do handle IFREQs that reach across components? Whatever short-term benefit you might reap from this exercise might well relegate you to the doghouse down the line. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Juergen Kehr Sent: Wednesday, July 22, 2015 1:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question I don't think, that checking Program Directories is a real good solution. Even more our CSI contains several fairly old products, for which it is really difficult to find a copy of the program directory. On the other hand I believe, that an automated solution is possible, because SMP/E itself always knows which DDDEFs are required. Juergen ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
