Sorry for coming in very late in this one... I was just reading through this whole thread, and I was thinking this... It is probably over-simplified...
If co-existence exists between 1.9 ; 1.8 ; 1.7... Then in SYS1.LINKLIB have GIMSMP17,18,19, also a IEBCOPY16 and IEBCOPY19, because no changes occurred in between etc... The same there should be multiple copies of programs / utilities / libraries that differ in between releases... Then in the SMP/E proc, have a &REL parm that is added to any program that is used that can make a difference... This way, if I have a 1.7 system (Prod) and a 1.9 system (Test) There should not be any problems for me provided the sysprog is awake and his doco is updated... Herbie -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jacobs Sent: 14 Januarie 2008 07:27 nm To: [email protected] Subject: Re: zOS 1.9 IEANUC01 Mark Zelden wrote: > On Sat, 12 Jan 2008 10:09:46 -0500, Mark Jacobs <[EMAIL PROTECTED]> > wrote: > > >> I use the same SMPE procedure to run the RECEIVE and then the APPLY. If >> the level of SMPE in the steplib'd MIGLIB is different than the level of >> SMPE in production the RECEIVE fails as I described earlier but the >> steplib is needed for the APPLY. Using the same procedure for both >> functions is a catch22. >> >> My solution is to have a separate procedure (without the steplib) for >> the receive and a procedure with the steplib for everything else. >> >> But I agree that it would be a good thing for SMPE to come up with a >> method of making it more idiot proof. >> >> > > During migration - until all systems are at the new level, you should > be able to use the STEPLIB job and point your classpath in your > client DD to your service directory for the uplevel system (obviously > the uplevel root needs to be mounted). Then you can use the same > procedure for everything: > > classpath="/service/usr/lpp/smp/classes/" > > Mark > -- > Mark Zelden > Sr. Software and Systems Architect - z/OS Team Lead > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > mailto:[EMAIL PROTECTED] > z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > > > Thats a very good idea, Thanks. -- Mark Jacobs Time Customer Service Tampa, FL ---- Riley: Find the next number in the sequence: 313, 331, 367, ...? what? The Doctor: 379. It's a sequence of happy primes, 379. Martha: Happy what? The Doctor: Just enter it! Riley: Are you sure? We only get one chance. The Doctor: Any number that reduces to one when you take the sum of the square of its digits and continue iterating until it yields 1 is a happy number, any number that doesn't, isn't. A happy prime is both happy and prime. ---- Doctor Who episode "42" ---------------------------------------------------------------------- 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 Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator ---------------------------------------------------------------------- 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
