chaat
Sophomore Member
Posts: 59 
|
Post by chaat on Jun 2, 2013 14:03:24 GMT -5
Hi Everyone,
The VSAVE command could be a great replacement for the RECOVERY ON feature in ISPF. For me personally the problem that I have is that when I'm coding, I forget to issue the VSAVE command on a periodic interval. To solve that problem, I would like to propose the addition of 3 parameters which could be used on the VSAVE command
AUTO-INTERVAL nnn This would cause the VSAVE command to be executed every nnn
mnutes. I would be open to having the interval be in keystrokes if that were the consensus. The key for me is to have the VSAVE command be executed on a periodic interval.
SAVE-PURGE When a SAVE command is issued, it would delete all the existing VSAVE files. This would save space in the VSAVE directory.
AUTO-OFF This would turn off the AUTO-INTERVAL functionality.
Thanks,
Chuck H
|
|
|
|
Post by George on Jun 2, 2013 15:14:44 GMT -5
Hi Chuck,
Sounds like a good idea. Right now, the VSAVE files are deleted when the edit session is END'ed. Is that sufficient? I'm not sure cleaning up at a normal SAVE time is warranted, the VSAVE files don't really impact anything (unless you're VERY tight on disk space).
Myself, a keystroke count would work best. I'd like to hear some other views on this; time or keystrokes?
George
|
|
|
|
Post by George on Jun 3, 2013 9:20:51 GMT -5
Robert,
I wouldn't worry about linking I/O operations to low level KB activity. If it was a concern, everything in SPFLite is a problem. Remember (Enter) is a KB primitive, just think of the activity that takes place in THAT primitive code.
The problem with timers in our structure is that, like file watching, knowing what tab a timer 'belongs to' is problematic as tabs get opened and closed. It would probably be better with a single timer triggering a global routine to scan all tabs for whether its VSAVE time or not. This would also avoid placing more code in tab swap, which is already a messy area.
George
|
|
|
|
Post by George on Jun 3, 2013 10:44:51 GMT -5
Sure, if a user was doing 'scattergun' editing amongst a bunch of different tabs, then when the timer popped there could be more than one needing a VSAVE (depending on the user's criteria, and activity in each tab etc.), but I very much doubt it would be noticeable. After all, we handle the UNDO snapshots on EVERY interaction that changes data, here we're talking certainly no more often than once a minute, probably longer. As I said, SWAP is messy, I'd rather avoid it.
George
|
|
Fredashay
Freshman Member
Noob writing a Q&A site in PHP and MySQL.
Posts: 12
|
Post by Fredashay on Jul 29, 2013 18:54:22 GMT -5
For my 2 cents, I'd just suggest RECOVERY ON and RECOVERY OFF as primary commands. Do the vsave whenever an arrow or other cursor movement key is pressed and something has changed since the last vsave. This would most closely mimic the mainframe, IMO. And then an option on the options screen that says whether recovery files are deleted or not when you close the program (you should be able to edit them as ordinary text files).
|
|
|
|
Post by George on Jul 30, 2013 15:14:19 GMT -5
Fred:
SPFLite basically has two levels of backup.
If UNDOLEVELS > 0 then following any interaction (think 3270 attention level - i.e. Enter, Function key, etc.) the session is saved for UNDO/REDO usage. This saving is not a transactional type save, but a file snapshot type save of the internal data areas. Of course this data is limited to the number of UNDOLEVELs, and disappears when SPFLite ends, the files are all in the users \TEMP folder under weirds temporary names. The files are all discarded when the edit session is closed.
The VSAVE backups are (right now) only created on a VSAVE command. They are kept in the \VSAVE folder with recognizable filenames so that a simple folder browse can recognize them. But only one VSAVE file is available per edit session, it is always the last VSAVE performed. The intention is to provide a recovery from a full program crash, lost power, etc.
It is certainly possible to just create a VSAVE on any change interaction, the downside is simply performance. If this were done on every change interaction, and UNDOLEVELS > 0 were also active, it would mean writing the entire data for the edit file to disk twice for every interaction (once for UNDO, once for VSAVE). On small files, this may not even be noticeable, but on large files it could cause noticeable delays.
George
|
|
