Checking v2.5 commands

George,

You mentioned in Robert's recent post about column ranges on line commands that you were looking at the primary commands for v2.5.

I would like to offer the following 'food for thought' ...

  Here's a question: Is SPFLite aimed squarely at ISPF users or does it aspire to being an exceptional PC-based text Editor in its own right?

  

  I think you've gone far enough with 100% ISPF compatibility.

  SPFLite is perfectly usable by people used to ISPF/PDF. And where it does differ, it is usually because of an enhancement, which those users will embrace or ignore.

  IMHO, the documentation also spends too much time 'explaining/making excuses' why SPFLite doesn't do exactly what ISPF does. I think that should also be changed (happy to help with the documentation this!).

  If SPFLite is to appeal also to users without IBM mainframe experience, the many references to ISPF in the documentation are unhelpful/irrelevant anyway, possibly even discouraging.

  Such users would probably benefit from a line or three about the (for them) unusual display format, distinction between line and primary commands, etc.

 

Command Chaining:  (I do not mean entering multiple commands at once separated by semicolon, but the 'other' sort.)

   Maybe you should survey the population (I appreciate they're not all members of this forum) if they use this facility.
   I think it is potentially useful, but appears very complex and thus I figure most people will find other ways to achieve the result they seek.
   I certainly haven't found enough enthusiasm to learn the concept sufficiently to be confident that I can apply it reliably.

   My main concern is that it is easy to mess it up when one of the earlier commands doesn't quite do what I had intended, eg. identifies the wrong subset of lines on which to subsequently act.

   So I prefer the approach of 'NX or X ALL + FIND what I want to work on and then do it' because it makes mistakes more obvious, and I can clearly see (and adjust) which lines will be affected BEFORE I change the file.

   There must be code associated with this feature which is potentially an opportunity to reduce complexity for future bug fixes and enhancements.

ACTION
   I appreciate this is a PROFILE setting, but I think it is poorly named.

   Calling it SAVEACTN would give the user a hint regarding the function to which the 'action' relates.

  

   The concept of an automatic, periodic SAVE function sounds sensible, but I wonder how few users actually change the default to a number other than 0.

   Whether the 'n' value is a count of ATTN events or timed settings matters not.

   Either way, the 'SAVE' event is not especially predictable, so a user can never be certain what has/has not yet been SAVEd.

   And often, a single 'logical' change (e.g. to source code), requires multiple 'physical' changes to different parts of the file/code and the SAVE events are likely to occur at 'illogical' intervals.

   Born out of the rather less reliable 'up-time' resilience of the 1970s, is this actually a function which users appreciate in this day and age?
   Assuming it is, I suggest a better place for it is as an operand to the SAVE command, e.g. SAVE EVERY 'n'

   If you absolutely must have single commands for EVERY profile setting, simply SET ALIAS.ACTION (or SAVEACTN) =  "SAVE EVERY "

  

BROWSE vs VIEW
   I don't see the need for the duplication of what is essentially the same thing. The differentiation between the two is negligible.

   Browse allows no file changes and no 'save' commands

   View allows file changes but limits 'saving' to SAVEAS, CREATE or REPLACE

   If a user wishes to have the effect of VIEW, i.e. the data can be modified but cannot be written back to the original file, the safe and proper way is

    - open the file in EDIT

    - immediately issue a SAVEAS <newname>

    - and then do whatever you want.

RETRIEVE, CRETRIEV and RETF
   I cannot imagine why anyone would want to retrieve any of the commands that merely reposition the screen.

   Currently we can filter by length of command. This creates further opportunities for inconsistent behaviour.
   For instance, I set "Minimum command length for RETRIEVE" to 3 bytes. So UP is excluded, but UP 6, or UP MAX is not.
   The length setting must apply to more than just the actual command, otherwise 'real' commands like F 'ABC' would not be retrievable.  
   I think you should consider specifically excluding certain commands (in all their forms) from being RETRIEVable.
   My starter set for this list is: TOP, BOTTOM, UP, DOWN, LEFT, RIGHT, RECALL/RC

SAVE/SAVEAS
   For consistency, should SAVEAS offer the same 'selection' operands as CREATE/REPLACE, ie. line-control-range, X/NX and U/NU ?