On Tue, 5 Dec 2006 08:44:52 -0600, Joel C. Ewing wrote: >Finally, someone else with the same problem. > >We also hit this with z/OS 1.4 and it still is with us on z/OS 1.6.
We are at 1.7 >.... You don't by any >chance have SPIFFY (SPF?)? Not here. I had 5 entries in the table and 4 orphan BACKUP data sets. I deleted the orphans with no apparent ill effects. I reused all 5 entries by starting 5 edits in 5 split screens. > >... If you are in edit, make changes (creating a BACKUP >dataset), save the member but stay in EDIT, the BACKUP dataset is not >deleted at that point yet is no longer active. If you end the edit >session, the BACKUP dataset is deleted; but if instead your TSO session >times out for inactivity while still in edit, the BACKUP dataset is not >deleted and becomes an orphaned BACKUP dataset. I used GSF's FASTPATH LOGOFF command to verify that this happens. Then I started another edit session and ISPF had no problem reusing that slot in the EDRT with a different data set. > >Eric wrote: >> We are having a problem with "orphaned" edit recovery datasets. >> ... All entries >> have a DISP of "D" and a mode of "E". Seems to be E for edit or V for view. >> 2. Why are the 6 non-existant entries still in the ISREDRT table? ISPF doesn't seem to delete the entries from the table, but just set the STATus to 0 to indicate that recovery is not needed. >> 3. How can the catalog and the ISREDRT table be syncronized? Seems safe to just delete the unused data sets. -- Tom Marchant ---------------------------------------------------------------------- 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

