|
View previous topic :: View next topic
|
| Author |
Message |
Renato Zangerolami
New User
Joined: 06 Dec 2019
Posts: 28
Location: Brazil
|
|
|
|
there is a way to disable the message:
warning - the UNDO command is not available until you change your edit profile using the RECOVERY ON command.
I know that when I type the command RECOVERY ON the message does not appear anymore.
What I want to know is whether you can disable this message, as I don't see the need for this message to keep showing up in the dataset at all times. |
|
| Back to top |
|
 |
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
Of course it does not appear after you turn on recovery because it is not off!
And if you do not want the message to appear and you do not want to turn on recovery then do not use the UNDO command. UNDO restores your data to the last checkpoint - checkpoints are only made when recovery is on. |
|
| Back to top |
|
|
Renato Zangerolami
New User
Joined: 06 Dec 2019
Posts: 28
Location: Brazil
|
|
|
|
I think it would be easier to ask:
is there a way to always leave the UNDO command enabled?
That is, when creating a data set, the recovery on function is already enabled. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2141
Location: USA
|
|
|
|
| Renato Zangerolami wrote: |
I think it would be easier to ask:
is there a way to always leave the UNDO command enabled?
That is, when creating a data set, the recovery on function is already enabled. |
The RECOVERY status is not attribute of the dataset; it is rather an option for particular TSO user to be enabled using UNDO command in his own EDIT sessions with specific dataset.
That's why it definitely cannot be set at dataset creation time, or whatever else.
The RECOVERY requires some resources to be allocated, for each pair of TSOID<-->DSNAME (which goes to endless amount). That's why (I guess so) the RECOVERY is not set to ON by default, or forever. |
|
| Back to top |
|
|
Renato Zangerolami
New User
Joined: 06 Dec 2019
Posts: 28
Location: Brazil
|
|
|
|
I think that if RECOVERY ON could be a user's choice to leave it enabled or not it would be interesting, because in my case I always have to enable this option, I believe that for all users this function is important.
Is there an advantage for the user that the RECOVERY will be disabled by default?
I think that if RECOVERY was already enabled by the system it would be more interesting. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2141
Location: USA
|
|
|
|
| Renato Zangerolami wrote: |
I think that if RECOVERY ON could be a user's choice to leave it enabled or not it would be interesting, because in my case I always have to enable this option, I believe that for all users this function is important.
Is there an advantage for the user that the RECOVERY will be disabled by default?
I think that if RECOVERY was already enabled by the system it would be more interesting. |
Please, read my explanation above. It would be more interesting also to set each mainframer's minimum salary to $500,000,000/year, but you can dream of it as long as you like...
Furthermore, in specific installations (to save resources), the system can reset RECOVERY to OFF for some users/DSNAMEs where it had been set ON previously. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
You only have to do it once per dataset. If you are doing it each time then either someone else is turning it off or the dataset has been deleted and recreated. For the latter I do not know if this right as the recovery option is part of your profile.
I have been googling this and I see that nowadays you do not need RECOVERY ON as long as you use SETUNDO. |
|
| Back to top |
|
|
Renato Zangerolami
New User
Joined: 06 Dec 2019
Posts: 28
Location: Brazil
|
|
|
|
that exactly what happens Nic, I need to use the command only once.
One thing I noticed is that when you create a PDS dataset, if you activate the recovery on command for one member, the other members automatically change to RECOVERY ON as well. Whether creating a new member or editing one that already exists.
Sergey, who dreams of a $ 500,000,000 / year salary must be you and not me, so I don't need to dream about it. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2141
Location: USA
|
|
|
|
| Renato Zangerolami wrote: |
| One thing I noticed is that when you create a PDS dataset, if you activate the recovery on command for one member, the other members automatically change to RECOVERY ON as well. |
RECOVERY option is set for the whole dataset, but not for a particular member.
It's a pity that you could not understand other issues I tried to clarify. |
|
| Back to top |
|
|
Renato Zangerolami
New User
Joined: 06 Dec 2019
Posts: 28
Location: Brazil
|
|
|
|
| I'm sorry Sergey, I have only 1 year of experience with Mainframe. I'm certainly aware of everything you write, but sometimes something goes unnoticed that I couldn't understand. But over time it gets better. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| sergeyken wrote: |
RECOVERY option is set for the whole dataset, but not for a particular member. |
Actually, there are two recovery facilities; they are entirely independent of each other.
The first is a recovery facility for the rarely used TSO line mode EDIT command. This facility is specified through the TSO PROFILE command -
PROFILE RECOVER / NORECOVER
The second is the ISPF EDIT RECOVER. It is specified through the ISPF EDIT profile, and I think this is the facility we have been discussing.
I believe sergeyken is incorrect about the scope; it is in effect for the element being edited - a member if you are editing a member of a PDS, or the entire data set if you are editing a sequential data set. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1315
Location: Vilnius, Lithuania
|
|
|
|
| RECOVERY can be set to ON in the ISPF configuration table. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1315
Location: Vilnius, Lithuania
|
|
|
|
| You can set up your own ISPF configuration table using the "ISPCCONF" command. Expect your support less than supportive about it. |
|
| Back to top |
|
|
Renato Zangerolami
New User
Joined: 06 Dec 2019
Posts: 28
Location: Brazil
|
|
|
|
| Thanks Prino, this is exactly what I was looking for. |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2594
Location: Silicon Valley
|
|
|
|
I thought these types of settings were kept in the edit profile. There is a profile for each low level qualifier, and if I recall correctly, there were up to 15 such profiles kept.
For example, these would use the same edit profile:
PEDRO.TEST.EXEC
PEDRO.V1R1.EXEC
In general, you can control the setting. In the editor, I think you can use:
PROFILE command to display the current settings
PROFILE UNLOCK if it is currently locked
RECOVERY ON to change setting if needed
PROFILE LOCK so that it will not change.
but you would have to do it for each low level data set names used. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2141
Location: USA
|
|
|
|
| steve-myers wrote: |
| I believe sergeyken is incorrect about the scope; it is in effect for the element being edited - a member if you are editing a member of a PDS, or the entire data set if you are editing a sequential data set. |
For thousands of edited PDSes, I always had to issue RECOVERY ON only once per library, to set it on for any member of this library, even for those not created yet.
Periodically, at some specific client installations, it becomes reset again to RECOVERY OFF, by system support, either automatically, or manually (we are not informed of that). That's why I need to repeat RECOVERY ON from time to time, but only once per library. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| Quote: |
I believe sergeyken is incorrect about the scope; it is in effect for the element being edited - a member if you are editing a member of a PDS, or the entire data set if you are editing a sequential data set.
|
I respectfully disagree ...
the scope is ALL the datasets covered by the same ISPF EDIT PROFILE
or in other words all the datasets with the same last qualifier
just tested ,
allocated two PD datasets with the same last qualifier and
issuing RECOVERY ON/OFF a few times and switching between the two datasets
the last setting was kept and applied
and when issuing the PROFILE COMMAND You should notice
| Code: |
EDIT ENRICO.TEST2.RECOV(A) - 01.00 Columns 00001 00072
Command ===> Scroll ===> CSR
****** ***************************** Top of Data ******************************
=PROF> ....RECOV (FIXED - 80)....RECOVERY ON....NUMBER OFF.....................
=PROF> ....CAPS OFF....HEX OFF....NULLS ON STD....TABS OFF....SETUNDO STG......
=PROF> ....AUTOSAVE ON....AUTONUM OFF....AUTOLIST OFF....STATS ON..............
=PROF> ....PROFILE UNLOCK....IMACRO NONE....PACK OFF....NOTE ON................
=PROF> ....HILITE AUTO CURSOR..................................................
****** **************************** Bottom of Data ****************************
|
that the profile name matches the last dataset qualifier
people forgetting this behavior usually get burned by the NUMBER and PACK profile settings
NUMBER destroying data
PACK causing varios abends in the programs reading the member |
|
| Back to top |
|
|
hankoerlemans
New User
Joined: 25 Jan 2018
Posts: 62
Location: Australia
|
|
|
|
The PROFILE mechanism is adequately described in ISPF help.
Unless disabled you might find the INITIAL MACRO field easier to deal with - assuming you have a user exec/clist allocated.
| Code: |
ISREDIT MACRO
ISREDIT (S1,S2) = RECOVER
WRITE &S1 &S2 &LASTCC
ISREDIT (NOW) = SETUNDO /* Value is blank if undo not available */
WRITE &NOW &LASTCC
ISREDIT RECOVERY = ON
ISREDIT SETUNDO = RECOVERY
WRITE &LASTCC
|
I don't know whether this is a bug but if you use the config table to
force the recovery warning off, it's off !
Hope IBM ain't watching.
 |
|
| Back to top |
|
|
hankoerlemans
New User
Joined: 25 Jan 2018
Posts: 62
Location: Australia
|
|
|
|
| Doh ! I tested on z/OS 2.4 ! |
|
| Back to top |
|
|
|
|
