On Thu, 5 Apr 2012 04:40:58 -0500, Elardus Engelbrecht <elardus.engelbre...@sita.co.za> wrote:
>Edward Jaffe wrote: > >>On 4/4/2012 11:32 AM, Mary Anne Matyaz wrote: >>> I was actually trying to break a PDSE last week, so that I could get an >>> example of the IEBPDSE utility run against a hosed PDSE, and I couldn't >>> seem to break one. I have two sysplexes so I was randomly back and forth >>> updating from outside the sysplex, and it had no trouble at all. Does >>> anyone have a fool proof way to break a pdse, on 1.13? > >>You must live right. Almost every time I've accidentally updated a PDSE from >>outside the sysplex it has been immediately broken. I suggest you do >>concurrent ISPF 3.3 copy members to the target PDSE and/or LKEDs while also >>doing copy. > >Edward is right. I would humbly also suggest that your volumes are shared so >no enqueue can take place at all. Or at least, ensure nothing is keeping these >updates in a single row, but allow them to occur simultaneausly. > >You could try to submit all those jobs with TYPRUN=HOLD and then when ready, >release ALL of them. > >If you can't still break 'em, you certainly must be in a paradise... ;-D > I've run into various issues in the past because my client shares DASD between 2 sysplexes via MIM (MII) and of course that does nothing for PDSE since XCF is used to communicate the changes. Most everyone knows the rules, but with new faces around occasionally someone puts a development PDSE on a non-sms volume (the SMS pools aren't shared) into some QA CICS region on the production plex (just an example) and there are abends after someone makes an update. These haven't broken the PDSE(s) involved and if you remove all the "binds" (shutdown any asids using the PDSE) that has resolved the problem. This hadn't happened in at least a few years until last week. The SMS rules usually prevent it - until a technical someone "knows better" and allocates the PDSE on a non-sms volume by specifying the "secret" STORCLAS (only certain people are allowed to do this in the ACS routines). Anyway, where I'm going with this story is this recent APAR that closed and I'm wondering if it will "fix" this sort of sharing violation. http://www-01.ibm.com/support/docview.wss?uid=isg1OA38306 OA38306: PDSE INDEX REDRIVE NOT BEING INVOKED ON ABEND0F4 RC24 RSN145AA033 FAILURES RSN2402C021 RSN145AC021 RSNS_REDRIVE_NEEDED APAR statusClosed as program error. Error descriptionPDSE index redrive processing is not occurring for RSN145AA033 IGWISRCH_INDEX_PAGE_DAMAGED PDSE index read failures resulting in an 0F4 dump with reason code RSN2402C021 RSNS_REDRIVE_NEEDED or RSN145AC021 RSNS_REDRIVE_NEEDED ( 2402C021 145AC021 ) . Index redrive should be attempted with RSN145AA033 as this reason code can indicate a error in the cached copy of the PDSE index page. Index redrive processing will flush the cached index pages and reread read the index from DASD. The failing read will then be redriven against the refreshed index pages. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
