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. It
didn't seem to be a problem anyone else had noticed at the time, so it
looked like something unique to our configuration. You don't by any
chance have SPIFFY (SPF?)? I have no idea whether that is related to
the problem, but it was the only thing I could think of at the time that
might be different from the average ISPF configuration. You would think
if these was a generic problem, others would have noticed a multitude of
useless BACKUP datasets, taking up space and possibly even wasting other
resources by becoming DFHSM migration candidates, etc. Maybe not.
It was easier for us at the time to implement a circumvention rather
than pursue the problem, as we already had a weekend process in place
that was checking for edit recovery BACKUP datasets and correlating that
with the user's ISREDRT table (to warn unsophisticated ISPF users who
left things in Edit Recovery status for weeks or longer that they were
in danger of shooting themselves in the foot - after several managed to
loose month's of data that way). We merely enhanced that process to
detect orphaned BACKUP datasets that were over a week old and deleted
them. The week delay was added because ISPF may occasionally re-use one
of these idle datasets.
I think the problem became noticeable in 1.4 because the naming
convention for these datasets changed to allow many more concurrent
BACKUP datasets. I think I have even isolated a case where the stranded
datasets occur: 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. We have an compile
support EXEC used by application development which internally saves a
source member from EDIT while staying in EDIT, so for these users a
timeout with EDIT in this state is not unusual if the last thing they
did before leaving their terminal was a compile. If at some future
point ISPF decides to re-use the same name for a BACKUP dataset, it will
successfully use an existing dataset, but this doesn't seem to happen
much of the time.
We have never seen any bad effects from the inactive entries left in the
ISREDRT table itself.
Eric wrote:
We are having a problem with "orphaned" edit recovery datasets. The
current environment is z/OS 1.4 and it is SMS managed. If I look at
the catalog, a particular user has 13 ISRxxxx.BACKUP datasets on DASD.
If the ISREDRTS clist is executed, there are 7 entries in the ISREDRT
table, of which only 1 is in the catalog listing. The 1 valid entry
has a STATUS of 1 where the other 6 have a STATUS of 0. All entries
have a DISP of "D" and a mode of "E". The ISREDRT table was deleted
from the ISPTLIB concatenation and when it was rebuilt on next logon,
there were 0 entries in the newly created ISREDRT table. So this leads
to 3 questions:
1. Why are there 12 cataloged datasets that are not in the ISREDRT
table?
2. Why are the 6 non-existant entries still in the ISREDRT table?
3. How can the catalog and the ISREDRT table be syncronized?
Thanks,
Eric P. Hoag
Platinum IT Consulting
--
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
