APAR OA32369 fixed our issue, and we were able to apply our co-existence maintenance.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Meehan, Cheryl Sent: Monday, December 10, 2012 8:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 1.13 Coexistence Maint. and PDISC (Was: ... and DLSW) Chris- Thank you for sending your response. We should be in a position tomorrow evening to test to see if this APAR fixes our issue. I'll post when we have completed testing. Cheryl -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chris Mason Sent: Sunday, December 09, 2012 3:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 1.13 Coexistence Maint. and PDISC (Was: ... and DLSW) Cheryl > Has anyone else seen this problem? Yes - based on my having found two APAR documents which fit your description - once it has been "degaussed"! 1. OA32797: ACTPU FOR SWITCHED PU REMAINS IN PDISC STATE, FAILS TO ACTIVATE WITH IST380I ACTPU REQUEST ERROR MESSAGE AND SENSE 08010000 2. OA32369: ACTPU FOR SWITCHED PU REMAINS IN PDISC STATE, FAILS TO ACTIVATE WITH IST380I ACTPU REQUEST ERROR MESSAGE AND SENSE 08010000 Without checking in detail, these two look identical except for the APAR numbers! How did I find these APAR documents? Well, I used the following tokens in the IBM web site main page search function: APAR PDISC VTAM This produced "HIPER Fix List for VTAM in the z/OS Communications Server" which listed the two APARs. QED! http://www-01.ibm.com/support/docview.wss?uid=swg21316934 I guess you should examine the maintenance package and take the matter up with your IBM support. Incidentally, the fact that "backing" off the maintenance package restored the configuration back to a working status helped in knowing to check for possible APARs, don't you think? - Why did your post need "degaussing"? The primary reason is that you did not assign one of your local VTAM specialists to present the problem. From the way you presented the problem it is clear you are not such a specialist. For example, you set great store by the fact that your distributed SNA nodes are supported by DLSw - which is irrelevant.[1] I expect you would have insisted on DLSw being one of your search tokens - and this does not yield any actual APARs. - > The DLSW Controllers are at various locations across the country. There is no such thing as a "DLSw controller". I imagine what you really mean - but have got into the habit as describing as these fictitious "DLSw controllers" between you and your colleagues in your installation - are SNA "controllers", workstations of some sort, more precisely implemented as SNA type 2.1 nodes[2]. > They <the SNA Controllers> connect using DLSW Peering over a Cisco Network to > one of our OSA3 <assumed OSA-Express3> <features using> Ethernet > <adapters>[3] at our Data Center. The above is an improved description. > When the coexistence maintenance was put on the system, ALL <SNA> controllers > came up with a PDISC status, and the controllers failed to connect with an > 08010000 sense code. One small change might have permitted you to find APARs describing the problem. Incidentally, I'm guessing that the "coexistence maintenance" introduced the problem as maybe a faulty APAR not - as far I could see - admitted in the text of the APARs I found. > I displayed the Subchannel address for the Switched major node, ... A switched major node does not have a subchannel address! Here's the sample output from the z/OS Communications Server SNA Operations manual: <quote> d net,id=a04smnc,scope=all IST097I DISPLAY ACCEPTED IST075I NAME = A04SMNC, TYPE = SW SNA MAJ NODE IST486I STATUS= ACTIV , DESIRED STATE= ACTIV IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES IST084I NETWORK NODES: IST089I A04P882 TYPE = PU_T2 , ACTIV--L-- IST089I A04P883 TYPE = PU_T2 , ACTIV--L-- IST089I A04D8831 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8832 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8833 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8834 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8835 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8836 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8837 TYPE = LOGICAL UNIT , ACT/S IST089I A04P885 TYPE = PU_T2 , ACTIV--L-- IST089I A04P886 TYPE = PU_T2 , ACTIV--L-- IST089I A04D8861 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8862 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8863 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8864 TYPE = LOGICAL UNIT , ACTIV IST314I END </quote> I expect you mean the XCA major node. Note that an XCA major node is a bit special in that it is permitted to contain only one PORT statement. Other major nodes tend not to be sensitive to how many of the only or top level resource statements are defined within the major node. Here again is the sample output from the z/OS Communications Server SNA Operations manual: <quote> d net,id=xca1a,scope=all IST097I DISPLAY ACCEPTED IST075I NAME = XCA1A, TYPE = XCA MAJOR NODE IST486I STATUS= ACTIV , DESIRED STATE= ACTIV IST1021I MEDIUM=RING,ADAPNO= 1,CUA=0500,SNA SAP= 8 IST1885I SIO = 1234 SLOWDOWN = YES IST1324I VNNAME = NETA.CN1 VNGROUP = GP1A2A IST1105I RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS IST1106I XCA1A AC/R 21 NO 902D0000000000000000017100808080 IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES IST170I LINES: IST232I LN1A2A , ACTIV IST232I LN1A7B , NEVAC IST232I LN1A9C , NEVAC IST232I LN1AAA , NEVAC IST232I LN1ABA , NEVAC IST232I LN1ACA , NEVAC IST232I LN1ADA , NEVAC IST232I LN1AEA , NEVAC IST314I END </quote> Note "CUA=0500". > ... and it was in an allocated status. The hardware address being in "allocated" status permits the VTAM internal resources represented by the "LINE" statements to have "ACTIV" status - IIRC from the last time I "played" with such an XCA major node. > XCA major node was Active, and all lines showed active. If the adjacent link stations, the resource other than the SNA PU, where relevant, represented by the PU statements, were in a state other than "ACTIV", the underlying supporting resources, the XCA "LINE" statements, must necessarily be active. > Each Switched Major node showed active. It would be impossible for the resources represented by the switched minor node PU statements to show any sort of status if the encapsulating major node were inactive. > All PU's showed PDISC. "PDISC" is a status associated with the "adjacent link station". When VTAM and OSA logic is behaving correctly you will be lucky to spot this status. When you are unlucky enough to spot this status over a period of time, typically permanently, something in VTAM or OSA logic is wrong. Here is the explanation of the status from the z/OS Communications Server IP and SNA Codes manual: <quote> Resource state: PDISC Category: Short Resource status: Pending discontact response A node, such as a link station or physical unit, is being deactivated or disconnected. The discontact request has been sent to the appropriate PU services, but the response has not been received. </quote> - I think you can now work out why it needed a VTAM/SNA specialist to present this scenario. Anyhow, please be so good as to pass the resolution on to us. - [1] I would like to have given you a Wikipedia reference to DLSw so that you could appreciate why it is to all intents and purposes irrelevant. However the Wikipedia article is rubbish from the first line and goes downhill from there - I smell Cisco mischief! Perhaps you should just ask whomever in your installation actually understands DLSw and the DLSw configuration for an explanation of why it is incidental to this scenario. [2] They could be implemented as SNA type 2.0 nodes but they would be quite considerably out-of-date. [3] I tend to prefer not repeating a word already present in the abbreviation! - Chris Mason On Tue, 4 Dec 2012 13:46:17 +0000, Meehan, Cheryl <cmee...@cswg.com> wrote: >Folks- > >We put Z/OS 1.13 Coexistence Maintenance on our Z/OS 1.11 system on Sunday >during our maintenance window. > >The DLSW Controllers are at various locations across the country. They >connect using DLSW Peering over a Cisco Network to one of our OSA3 Ethernet >adapters at our Data Center. > >When the coexistence maintenance was put on the system, ALL DLSW controllers >came up with a PDISC status, and the controllers failed to connect with an >08010000 sense code. >I displayed the Subchannel address for the Switched major node, and it was in >an allocated status. >XCA major node was Active, and all lines showed active. >Each Switched Major node showed active. >All PU's showed PDISC. > >When the co-existence maintenance was rolled back, all DLSW controllers came >up with no issues. > >Has anyone else seen this problem? > > Cheryl Meehan ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
