UA69565 http://www.ibm.com/Search/?q=UA69565&co=us&lo=any&sn=&lang=en&cc=US&en=utf&hpp= ftp://ftp.software.ibm.com/eserver/zseries/holddata/quarter.txt ++HOLD(HDZ1D10) FMID(HDZ1D10) REASON(AA42179) ERROR DATE(13365 ) COMMENT(SMRTDATA(FIX(UA69565) SYMP(PRF) CHGDT(131231)))
UA71730 http://www.ibm.com/Search/?q=UA71730&co=us&lo=any&sn=&lang=en&cc=US&en=utf&hpp= ftp://ftp.software.ibm.com/s390/holddata/year.txt ++HOLD(HBB7780) FMID(HBB7780) REASON(AA43690) ERROR DATE(13352) COMMENT(SMRTDATA(FIX(UA71730) SYMP(FUL) CHGDT(131218))) On Tue, Mar 4, 2014 at 8:25 AM, Staller, Allan <[email protected]> wrote: > UA69565 closes APAR OA42179 > UA71730 closes APAR OA43690 > > As of a few minutes ago, neither PTF was indicated as a PE. > I checked the cover letters for the z/OS 2.1 versions of those PTF's > (UA69566 and UA71731) and of the 2 I would consider UA71730 the most likely > culprit. > > I would check you apply run for failures during the application of these > PTF's, or bypass of a pre -req. Can you post the SMPOUT from your apply run? > I can't think of anything else that would cause this. > > <snip> > But through some slow application of maintenance I determined the 2 that PTFs > that cause the DW are UA69565 and UA71730. I've no idea why they cause an > issue, but when I apply them I get the DW. To make it even more odd is those > PTFs are applied to other z/OS 1.13 systems I run. > </snip> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
