OA17218 closed with PTFs. We appreciated the original heads up as we
have been in the process of replacing some older storage processors with
new technology so we made the workaround known to the folks responsible
for handling the IODF changes. Thanks, Sam
APAR Identifier ...... OA17218 Last Changed ........ 06/09/06
RANDOM OVERLAYS DUE TO INCORRECTLY BUILT SSCB TABLE
06/07/12 PTF PECHANGE
Symptom ...... IN INCORROUT Status ........... CLOSED PER
Severity ................... 1 Date Closed ......... 06/08/21
Component .......... 5695DF111 Duplicate of ........
Reported Release ......... 1J0 Fixed Release ............ 999
Component Name DEVICE SUPPORT Special Notice PE HIPER
Current Target Date ..06/09/01 Flags RESTART/BOOT/IPL
SCP ...................
Platform ............
Status Detail: SHIPMENT - Packaged solution is available for
shipment.
PE PTF List: UA18400 UA18402 UA18401 UA20831 UA20830 UA20832
UA20833
PTF List:
Release 1G0 : UA28564 available 06/08/30 (F608 )
Release 1H0 : UA28565 available 06/08/30 (F608 )
Release 1J0 : UA28584 available 06/08/30 (F608 )
Release 1K0 : UA28585 available 06/08/30 (F608 )
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
An an OUCB was found to be overlayed by an SSCBDH overrunning
its length, causing an abend0c4 pic10 IRASAMSU/UA15188+998. The
SSCB table is built incorrectly overlaying MVS control blocks.
.
The sequence that causes this failure:
1) An IPL or initial Vary Online of DASD device in SSID.
Ex. 10 devices for this example
2) Configuration change to delete some devices with this SSID
Ex. 5 deleted for this example
3) Configuration change to add devices with same SSID
Ex. 3 added for this example
---> Problem: New Table built and size getmained is
for 8 devices. However device counter
still set to 10.
4) Now, 2 more devices are re-configured / added back to
this SSID. Device counter is off so we think we
have room for 2 more devices in the table. Getmained
area was only for 8....so we overlay storage following.
.
Additional abends observed, though there may be others:
IAXVP/HBB7709+A00 abend0c4 pic4
IAXIR/HBB7709+766 abend6c5 rsn1c023120
IRARMINT/HBB7709+69E abend15f rsn18
IRAQUEUE/UA16164+141A abend15F rsn0152
IAXIS/UA13982+1c9e abend0c4 pic10
.
LOCAL FIX:
Avoid reconfiguration for an SSID that currently
has any devices already online to that host.
.
Bypass process below is discussed in TECHDOC ITEM S1002495
.
There are only 2 bypasses for deleting and re-defining
the SSSCB Device Table:
A) IPL
-OR-
B) Follow the procedure below (from S1002495) to
manually delete and re-define. At least one
volume will have to be varied offline while
this procedure is done.
.
****Delete / Redefine Procedure****
1) Make sure one device is taken offline. Yes it can be a
dummy device, or it can be any other device in the SSID.
- Pick the device in the SSID you can most afford
to have offline.
2) Issue the DELETE command: " DS QD,SSID=xxxx,DELETE "
This will delete the current device table.
**IMPACT - limited to a small timing window for products
that use that table. This would include SDM
(like flashcopy), SMS, and RMF. The last two are
strictly related to statistics gathering.
3) Vary the offline device, or devices, online.
4) Then issue the VALIDATE for each string of devices. For
example, if a given device string began at a000 and there
were a total of 256 devices, then you would issue:
DEVSER QD,A000,256,VALIDATE
.
The offline devices will be added back in to the table
by the VARY ONLINE in #3. The existing online devices
will be added back in by the VALIDATEs you do for every
device/string of devices (#4).
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: DFSMS USERS DYNAMICALLY ADDING D/T2105 *
* D/T2107 D/T1750 D/T3990 WITH 2 CONTROL *
* UNITS HAVING THE SAME SSID *
****************************************************************
* PROBLEM DESCRIPTION: RAMDOM OVERLAYS OCCURS IN THE SYSTEM *
* AFTER DYNAMICALLY ADDING NEW DASD *
* CONTROL UNITS. THE OVERLAYS CAN CAUSE *
* ABEND0C4 IN VARIOUS COMPONENTS. THIS *
* WILL ONLY OCCUR IF THE CONTROL UNITS *
* HAVE DUPLICATE SSIDSWHEN ATTEMPTING TO *
* VARY ONLINE THE NEW DEVICES. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
CODE WAS CHANGED TO CORRECT THE SIZE OF THE CONTROL BLOCKS TO
REFLECT TOTAL DEVICES AVAILABLE NOT THE NUMBER OF DEVICES
PREVIOUSLY BROUGHT ONLINE.
PROBLEM CONCLUSION:
TEMPORARY FIX:
*********
* HIPER *
*********
COMMENTS:
MODULES/MACROS: IECCINIT
SRLS: NONE
RTN CODES:
CIRCUMVENTION:
MESSAGE TO SUBMITTER: .
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Brian Peterson
Sent: Friday, July 14, 2006 7:31 AM
To: [email protected]
Subject: Heads-up: OA17218 Serious problems for dynamic changes to DASD
There apparently is a flaw in the process of changing the SSCB table
representing DASD control unit SSIDs.
The flaw is exposed when making dynamic configuration changes to DASD
devices - specifically, when adding or removing devices from an already
online string represented by a particular SSID. The code incorrectly
maintains the number of device entries in the SSCB table, and therefore
when resizing the SSCB table to accomodate changes in the number of
devices in an SSID, can overlay other MVS control blocks.
Check out OA17218 for details, as well as a Rube Goldberg-esque
workaround to avoid the overlay if you need to make a dynamic
configuration change that would result in an overlay.
I'd suggest trying to avoid falling into this particular snake pit. The
list of additional symptoms sounds nasty to me!
Brian
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
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
