In our shop we merge only z/OS serverpac files so we do not have conflicting member name issues. The serverpac install will change the CSI entries to point to the dataset where you merged the files. We have applied z/OS maintenance with no need to re-merge. We do however use LIBDEFs for non z/OS serverpac products.
With a shrinking staff and management pushing things like ITIL and COBiT we have little time to manage REXX execs especially when we do not see any significant performance issues in ISPF. With the mainframes being decommissioned in the near future (sic) the effort to convert to LIBDEFs at this time is not high on our task list. I would also like to mention we rename all z/OS serverpac datasets to a two level name because the second level names are unique. Regards, Steve Wolf Rockwell Automation 414-382-4308 Pinnacle <[email protected]> Sent by: IBM Mainframe Discussion List <[email protected]> 12/17/2008 08:14 AM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: ServerPac Merging Datasets ----- Original Message ----- From: "Jousma, David" <[email protected]> Newsgroups: bit.listserv.ibm-main Sent: Wednesday, December 17, 2008 8:50 AM Subject: Re: ServerPac Merging Datasets > As Tom Conley pointed out, if you download his free package that contains > all the samples/examples you would ever need, all the heavy lifting is > done. My TSO logon PROC only has the minimum datasets in it, ISPF, and > USS, and our home customized datasets. Every other product is LIBDEF'd to > at the time the product is selected for use. For example, users wanting > to use SDSF execute a REXX exec called LDEFSDSF which on my system looks > like: > > ADDRESS TSO "ALTLIB ACT APPL(CLIST) DA('SYS1.ISF.SISFEXEC',", > "'SYS1.EOY.SEOYCLIB')" > ADDRESS ISPEXEC "LIBDEF ISPMLIB DATASET ID('SYS1.ISF.SISFMLIB',", > "'SYS1.EOY.SEOYMENU') STACK" > ADDRESS ISPEXEC "LIBDEF ISPPLIB DATASET ID('SYS1.ISF.SISFPLIB',", > "'SYS1.EOY.SEOYPENU') STACK" > ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID('SYS1.ISF.SISFSLIB') STACK" > ADDRESS ISPEXEC "LIBDEF ISPTLIB DATASET ID('SYS1.ISF.SISFTLIB',", > "'SYS1.EOY.SEOYTENU') STACK" > ADDRESS ISPEXEC "SELECT PGM(ISFISP) PARM("ZTRAIL") NEWAPPL(ISF)", > "PASSLIB NOCHECK SCRNAME(SDSF)" > ADDRESS ISPEXEC "LIBDEF ISPMLIB" > ADDRESS ISPEXEC "LIBDEF ISPPLIB" > ADDRESS ISPEXEC "LIBDEF ISPSLIB" > ADDRESS ISPEXEC "LIBDEF ISPTLIB" > ADDRESS TSO "ALTLIB DEACT APPL(CLIST)" > > Keeps things very neat and tidy. I expect though that this discussion is > more religious than technical however, and there is more than one way to > skin a cat. > Dave, Dynamic ISPF is my religion, but there are lots of technical reasons as well. - BLDL overhead is still significant when you have 100,000+ member ISPF libraries, vs. Dynamic ISPF where the BLDL is a lot less since what you're looking for is most likely in the LIBDEF'd libraries. - You can't secure any dialogs if they're all balled up into one big library vs. Dynamic ISPF where you can use SAF to protect the datasets for each dialog - Single-threaded access to single large ISPF library instead of multi-threaded access to multiple ISPF libraries - What do you do for member name conflicts? If you think that doesn't happen, you missed the JCLCHECK and APA collisions when they both used CAZ as a prefix. - After applying maintenance, you have to re-run the merge step Regards, Tom Conley ---------------------------------------------------------------------- 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
