Text from OA32369 included below. OA30776 appears to have been intended to resolve some problem related to timing of LSNCB PU PAB processing and delay that until some other event had occurred.
OA32369 talks about LSNCB having some value and PAB processing not being scheduled, which sounds to me like OA30776 may have had some bad side effects of causing a processing delay in some cases for which the delayed processing is never resolved. In any event, the rather nebulous "In certain conditions" description in OA32369 doesn't give much clue as to whether this is a rare or common problem, or what kind of devices might be affected other than the reference to "switched PU". I don't know if use of OSA FENET SNA is significant here, but at this point this is the only interface we have through which we can drive 3174 R controllers, and for us the failure on these devices was 100% with no circumvention. Since IBM is offering an APAR fix, I would hope that means they have already diagnosed and understand the problem. Joel C Ewing --------------------------------------- APAR Identifier ...... OA32369 Last Changed ........ 10/03/22 ACTPU FOR SWITCHED PU REMAINS IN PDISC STATE, FAILS TO ACTIVATE WITH IST380I ACTPU REQUEST ERROR MESSAGE AND SENSE 08010000 Symptom ...... IN INCORROUT Status ........... OPEN Severity ................... 3 Date Closed ......... Component .......... 569511701 Duplicate of ........ Reported Release ......... 1A0 Fixed Release ............ Component Name VTAM V4 MVS/ESA Special Notice Current Target Date ..10/05/21 Flags SCP ................... Platform ............ Status Detail: ANALYSIS - APAR is being investigated or debugged. PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: In certain conditions, the ACTPU processing for a switched PU might fail with the following message: IST380I ERROR FOR ID = xxxxxx - REQUEST: ACTPU, SENSE: 08010000 A display of the switched PU resource will show state of PDISC to indicate pending discontact response and the PU fails to activate and remains hung. The associated LSNCB will show LSNFSM value of x'9C' for LSN_SW_CONNECT_REQUESTED state and the RCCRNAA bits in RCCBITAN flags for the switched PU control block will show value of x'4' for RCCRNAT4 to indicate that CONTACTED x'0A' has been received. The VIT trace will show that the switched PU got sidequeued (non-zero LSNSIDEQ) and the PAB did not get scheduled to update the switched PU to the correct state of CONCT. LOCAL FIX: None. There is no certainty that forced deactivation and re-activation of the switched resources will work. KEYWORDS: IST380I ACTPU SWITCHED PU PUT2 PUT21 SENSE 08010000 PDISC CONTACTED 0A LSN_SW_CONNECT_REQUESTED LSNSIDEQ ISTACCQ4 RCCRNAT4 Q4CTD0A ----------------- On 03/22/2010 09:07 AM, Chris Mason wrote: > Joel > > Unfortunately I am not able actually to see what is said in APAR OA32369. > > I am however able to see what OA30776 says and it would be very difficult to > see any sort of a connection (sic)between APAR OA30776 and what you > describe that has become APAR OA32369. > > If you would like some try at analysing what OA32369 is saying, perhaps you > could post the contents. > > It may also be handy if you could find the VTAM - and/or hardware - error > messages which appeared at the time of the failed attempt to activate the > 3174 controllers. I expect that the errors would concern the SNA adjacent > link > station entity as identified by the name of the PU statement. Another > possibility is that the resources associated with the XCA definition failed > in > some way. These are all problems which would prevent activation of LUs at a > much earlier stage in the activation of SNA resources. > > Chris Mason > > On Fri, 19 Mar 2010 21:33:46 -0500, Joel C. Ewing <[email protected]> > wrote: > >> We put on about a year's worth of z/OS 1.10 maintenance in mid February >> to get things up to RSU1001++. May have included some corrective >> maintenance beyond RSU1001 that we could have done without, but >> everything seemed to be functional in our MVS test environment and >> looked OK to go live last weekend. >> >> We were forced to back out maintenance after encountering a problem now >> being tracked as APAR OA32369, which caused an outage for us on all SNA >> 3174-81R and 3174-23R controllers driven through a Fast Ethernet OSA >> adapter on a z9. The APAR OA32369 description is totally unclear to me >> as to what could be affected and how persistent the problem might be, >> but for us none of the LU's for coax-attached dumb terminals or >> coax-attached 4224 printers behind these 3174 controllers would activate >> after maintenance. This old hardware is being gradually phased out and >> has been so stable for so long we didn't even have any accessible from >> our test system. We do now! >> >> IBM indicated the problem may have been caused by FMID HVT61A0 PTF >> UA51696/OA30776, which I believe is on PUT 1002 and not yet assigned to >> an RSU; but at least as of Friday afternoon there weren't yet any PE >> holds on UA51696. We have been offered an APAR fix and will look at >> that option next week. >> >> -- >> Joel C. Ewing, Fort Smith, AR [email protected] > -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- 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
