Update on this !!
The fault was linked back to an ACF2 exit that was written specifically for the customer, even CA wasn't aware of it's existence. This exit is customer owned and has a copyright over it and hence we didn't maintain. This exit was rarely maintained and last updated back in 1997. CA will be assisting with an update once the ownership of the copyright has been proven to CA as the 3rd party no longer exists. A workaround usermod has been provided by CA to reduce the need to IPL to recover. We are stable at the moment. Thank you to everyone that offered support. Regards Yogeetha On Wed, Feb 25, 2009 at 4:04 PM, Yogeetha balasubramanian < [email protected]> wrote: > Firstly, i would like to thank you all for the immediate assistance and > sugessions. Since i am not involved directly into this account i am unable > to answer your questions right now. I have posed my questions back to them > > It appears to be a VSAM wait only. > > We have CA directly involved and already engaged with IBM to get some > dedicated assistance. > > I will get back to you all if the solution worked for me. > > Thanks Again Valued Members !! > > > > > On Tue, Feb 24, 2009 at 7:42 PM, Mark Zelden <[email protected]>wrote: > >> On Tue, 24 Feb 2009 08:03:16 -0600, Mark Zelden <[email protected] >> > >> wrote: >> >> >> > >> >ENQ problem with what? Was it with the ACF2 VSAM files? ISTR a HIPER >> >coming across my email very recently that talked about that. >> > >> >Did you open issues with ACF2 support for those outages and provide them >> >documentation, dumps etc.? >> >> I just checked my email... it wasn't and ENQ, it was a wait / hang. The >> problem affects 9.0 and 12.0: >> >> PRODUCT: CA-ACF2 MVS RELEASE: 12.0 >> >> APAR #: RO05222 DATE: 23 JAN 2009 >> >> PROBLEM DESCRIPTION: TA8580B: VSAM WAIT AFTER FORCE/CANCEL DURING I/O >> --------------------------------------------------- >> >> STARTRAK PROBLEM: 8580 >> ABSTRACT: VSAM WAIT AFTER FORCE/CANCEL DURING I/O >> >> DESCRIPTION: >> >> IF AN ADDRESS SPACE TERMINATES DURING ACF2 VSAM PROCESSING >> AND THE ESTAE DOES NOT GET CONTROL THE RPL WILL NOT GET >> CLEANED UP. THE NEXT REQUEST WILL GRAB A 2ND RPL AND COULD >> END UP IN A WAIT IN IBM VSAM MODULE IDA019SE ON RESOURCES HELD >> BY THE 1ST RPL. CODE WILL BE ADDED TO REMOVE THE USE OF THE >> 2ND RPL. THIS WILL FORCE ONLY A SINGLE RPL TO BE USED. THE >> ACF2 CODE WILL DETECT THAT THE RPL WAS STILL IN USE AND >> INITIATE ACF2 VSAM ERROR RECOVERY WHICH WILL ALLOW VSAM TO >> CLEAN UP ANY HELD RESOURCES. >> >> >> >> 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 >> >> ---------------------------------------------------------------------- >> 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
