On Thu, 19 Jan 2006 09:35:28 -0800, Skip Robinson <[EMAIL PROTECTED]> wrote: > > A customer's perspective. We recently had a problem for which IBM gave us > an APAR test fix. A while later they rewrote the fix so that it hit a > different MOD within the same LMOD. In that case, APPLY CHECK failed > because the new fix attempted to SUP another sysmod but did not contain the > same elements. For that case, SMP/E detects an error and quits. (Goodness.) > The proper way out was to RESTORE the first fix, which removed all traces > of it from the target zone, then APPLY the new fix. The result was clean: > correct version of code, SMP/E happy with all relationships. > Thanks for pointing this out. APARs IR44571 and IR46970 show that IBM is sometimes willing to provide enhancements to protect the CSI integrity against unwitting transgressions by providers (even including IBM itself). Maybe there's hope in this case.
Interesting. We also discovered our problem when we received a GIM32501E message. (Hmmm. M&C says "SUPERSEDE"; the actual message says "SUPERCEDE".) Feels like a SEV4 APAR to me. I vote with M&C.) But in our case, the error was detected only the second time we attempted to APPLY the reworked PTF; the CSI was already damaged. I also tried John Eells's suggestion of a coverup PTF; not a new one -- the original offender hadn't shipped yet, so I was free to experiment with it. By adding enough elements, I got the APPLY REDO to work without the GIM32501E. I then did the RESTORE and again tried to APPLY the smaller version. Once again, SMP/E reported GIM32501E on some (but not all) of the MOD elements it earlier reported. This leaves me curious concerning the algorithm used to generate the GIM32501E. What condition in the CSI caused that particular message, and was repaired for you (but not for us) when you RESTOREd the original APAR fix. > Although vendors are in the business of crafting PTFs, customers often > create usermods and therefore have to deal with the same issues. It's > valuable for everyone to understand the process. SMP/E almost always > provides a mechanism to correct problems like this. I can't remember the > last time we actually had to trash an entire CSI and start over. > Thanks for pointing out that the benefits of good validation by SMP/E extend beyond ISVs. If nothing else, by helping us to craft better SYSMODs, IBM keeps their service center phones quieter. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
