Mark Zelden wrote:
On Fri, 25 May 2007 14:17:24 -0400, Kirk Talman <[EMAIL PROTECTED]> wrote:
Have problem under 1.8. Had problem under 1.7 & 1.4. Oldest one of 131
total is now 2 yrs old. The only advice I got was to "delete ISPPROF and
see if that helps." Kind of answer I would expect from M$weenie not
IBMsysprog.
If you get a viable solution let me know.
fyi our main system is three plexes w/shared dasd. DSL w/mask of
*.ISR*.BACKUP shows 10260 datasets.
What exactly is the problem? Just that the data sets are out there? This
can happen if your session is canceled. Or is it that you edit something
and expect to go into recovery and don't - so therefore the recovery files
sit out there forever. If you use the same userid(s) on multiple LPARs
there is a valid explanation for that and it is WAD (or BAD).
See "ISPF Considerations" in $SNGLTSO on my web site in the
JOBs/DOC section or CBT file 434:
http://home.flash.net/~mzelden/mvsfiles/$sngltso.txt
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group: G-ITO
...
The problem first became apparent circa z/OS 1.4 when the ISPF editor
ceased restricting recovery dataset names to a small set of names. The
problem is not that TSO users fail to resolve edit-recovery pending
situations (well, that is a problem, but one that proper training might
resolve), but that edit recovery datasets are sometimes left on DASD
that are not associated with any pending edit recovery.
The problem (which has been discussed here previously) seems to be that
when SAVE is done in an edit session, the Edit Recovery dataset
association is broken, but the recovery dataset itself appears to be
retained until the edit session is ENDed (or another change is made and
the edit recovery relationship re-established). If the TSO session
terminates abnormally while you are still in edit in this state, the
recovery dataset becomes orphaned. Since there are no unsaved changes,
there is no edit recovery pending to cleanup the dataset; and since the
next edit session that needs edit recovery moves on to a different edit
recovery dataset name, the old edit recovery dataset is unlikely to be
reused. This basic problem may have existed for a long time, but until
the naming conventions for the recovery datasets were changed, the same
dataset name would quickly be re-used and the problem would have
resolved itself.
On a weekly basis we scan the TSO user MVS catalogs for all edit
recovery backup datasets and compare those with the pending edit
recovery sessions in that TSO user's profile dataset. This was
originally done to catch users who didn't understand the consequences of
not resolving pending edit recoveries after several unsophisticated TSO
users shot themselves in the foot and lost weeks of data entry. After
the orphaned entries started appearing, this same process was extended
to delete orphaned recovery datasets weekly. We originally did open a
PMR on this, but we didn't understand what was happening as well as we
do now and IBM couldn't duplicate the problem, which made us think at
the time there was some unknown interaction with other vendor products.
It was much simpler for us to implement a circumvention than pursue
this issue with multiple vendors.
Recent discussion here makes it appear this is a problem within ISPF
alone. Someone for whom this is a ongoing issue should open a PMR with
IBM if they haven't already done so.
--
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
