Also look at prior discussion on this list for "ispf edit recovery" from
May 2007:
For z/OS 1.4 and beyond, saving changes from an edit session (with
explicit SAVE) appears to break the edit-recovery relationship with the
backup dataset, but the backup dataset itself doesn't get deleted until
you exit normally from EDIT. If your TSO/ISPF session terminates
abnormally (like a timeout) while EDIT is in this state, the backup
dataset is not deleted and becomes orphaned. My understanding was that
an APAR has been taken to address this. Tom Conley references this as
OA23202
(http://www.mail-archive.com/ibm-main@bama.ua.edu/msg63271.html ), but
the description of that APAR (closed SUG) doesn't fit. Perhaps the
undocumented OA23616 is the correct APAR for this problem.
This problem may have predated z/OS 1.4, but perhaps would not have been
apparent until a change in the naming conventions for backup datasets
was made circa z/OS 1.4 that made re-use of a prior recovery dataset
unlikely.
JC Ewing
Thompson, Steve wrote:
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Eric Bielefeld
Sent: Tuesday, March 18, 2008 10:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: ISPF Backup Files
I believe that the way you described the backup datasets is the way it
works. If your TSO session times out, and you're in the middle of an
edit session, when you next do an ISPF edit, you get a message saying
you were editing such and such, and have the option to resume. If you
resume your edit, and then exit normally, the dataset goes away. At
least thats the way it worked in the past, with z/OS 1.2.
Eric
<SNIP>
Eric:
That's kinda my point. It is supposed to work this way, but NOT leave
orphaned backup data sets out there. And I am finding them, but I can't
tell how or why this is happening. All I know is that they are at least
1 week old or better (which is why they have been archived).
And to make matters more interesting, from hour to hour I may be on a
z/OS 1.9 system or a 1.8 or a 1.7 or even a 1.4. So who or which one(s)
are misbehaving?
The APAR someone mentioned (OA23616) doesn't even have a description in
it yet, it is so new.
So, something is not quite right. But my asking about this is because
I'm not sure what is really going on -- and the search I did with SIS
did not return the above mentioned APAR.
Regards,
Steve Thompson
...
--
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
