Thanks to all for helping. Now problem has been resolved by IPLing system from another RES volume and applying PTF to old RES volume where SMPE was pointing to. My apply Job run successfully. Thanks once again.
On Tue, Jan 14, 2014 at 12:41 PM, Jon Perryman <jperr...@pacbell.net> wrote: > Robert is correct. Pauls GIM69217I is also due to applying PTF's on a live > system. Both you and Paul only shot yourself in the foot but it could > easily been a shot to the head. Applying critical component PTF's to a live > system is dangerous. Only do this if you can tolerate the risk. If you do > risk it, have a second system available in case your system becomes > unusable. > > New secondary extents to a linklst datasets won't cause a problem unless > you do an LLA refresh. > > Pauls error occurred because an LLA module remained at the old version but > the non-lla module was immediately available / called. SMP/e verifies this > because it must occurs frequently for that module. Not all products check. > > Your error occurred because of a worse problem. SMP/e compresses a dataset > when it encounters an SB37 (dataset full). You had an SB37 against a > linklst dataset and it was compressed. Since LLA has TTR pointers, the > requested modules were no longer at their expected TTR location causing the > loader error. LLA refresh corrected the TTR pointers but it could > potentially make linklst incompatible with LPA forcing an IPL but the LLA > refresh was worth a try since your system was unusable. > > With this error, you probably have a PTF that was in flight and failed in > the middle. If that PTF was for a critical component (e.g. TSO, DFP, VSM, > MVS, LLA, JES2, SMP/e, nucleus, ???), then that component is probably toast > because of incompatible modules making your system unusable. > > There are documents available on how to do maintenance. I strongly > recommend you review some of them and get a better understanding on how to > do this in your environment. > > If want to risk applying to a live system, then you can do some things to > reduce the risk: > 1. Compress affected libraries before applying PTF's. > 2. Don't apply huge number of PTF's at one time. > 3. Apply critical component PTF's seperate from other PTF's. > 4. Always have another system available to apply PTF's if this system > becomes unusable. > 5. Don't IPL the system with an incomplete PTF installed (if possible). > > Jon Perryman. > > > > >________________________________ > > From: Robert A. Rosenberg <hal9...@panix.com> > > > > > >OTOH: You should not be doing SMPE Maintainance to the live system. > >If you are going against a maintenance set of SYSRES Volumes as > >opposed to the set you are IPL'ed from, going into a secondary extent > >is not an issue. Also, if you use PDSE datasets not PDS ones, the > >secondary extent issue may not exist (or is less) since as you edit a > >file, the old version's space is released back to free space and will > >be reused. With PDS, it becomes GAS and only is recovered by doing a > >compress. > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
