Just because you don't understand or can't imagine it's importance doesn't make
it non-sense. TSO edit has a batch mode without the need for a macro language
so you can't even check return codes. Yes they could have taken it to the
extreme but being extreme is not acceptable. In the MVS world, we often make a
compromise between what's acceptable and what should be the default.
As for imagining a syntax, are you implying that IBM could have easily resolved
this issue. To you this is a simple change, Thankfully that's not how IBM
operates and they consider the true impact. What is the effect in batch mode?
What happens to commands in the queue? What happens to command in SYSTSIN. Do
you flush to the next END statement? Has that END statement? If running a
macro, has it generated the END statement or should we start flushing SYSTSIN?
Does it flush SYSTSIN get flushed? Does it honor END parms? Will these changes
affect existing users?
As for saving keystrokes at the expense of everything else, that is typical
UNIX. We in the MVS world consider the whole picture Consistency between macro
versus interactive. Compare benefits of brevity versus impact on all users
(casual versus heavy).
Jon Perryman
On Saturday, August 9, 2014 2:16 PM, Paul Gilmartin
<0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Sat, 9 Aug 2014 13:29:32 -0700, Jon Perryman wrote:
>
>>For edit macro's, placing the cursor at the end risks far less data than
>>leaving the cursor alone. Right or wrong is a matter of opinion. Leaving the
>>cursor at the current location will certainly teach programmers to check
>>return codes and not make false assumptions the first time they destroy their
>>data because they didn't check the return code.
>>
>A nonsensical argument. Carrying that reasoning to the extreme,
>the safest thing to do on an unsuccessful search is to Cancel the
>edit session leaving the file unchanged and data intact.
>
>I suppose it's unfortunate that checking the return code is part of
>the macro language rather than of the host environment. Otherwise
>Edit could abort the macro if it issued
another command without
>extracting the return code.
>
>(I'd imagine some syntax such as:
>
> FIND Target Failure=failure-option
>
>... where the default failure-option is CANCEL.)
>
>And what you consider proper for a macro, I consider improper for interactive
>editing. For interactive editing, I place a premium on economy of keystrokes
>and hand motion. For example, ISPF Edit requires six keystrokes to search for
>a comma; another editor I use needs only three. (To be fair, each requires
>four to search for a period.) And rodent-oriented editors that pop up a dialog
>box to do a search are dreadful.
>
>Forget Case Insensitive Disambiguating Tables; forget lexical separation.
>I'd welcome:
>
>Instead of the terse
>
>f 'Foo Bar'<ENTER> fFoo Bar<ENTER>
>f c'Foo Bar'<ENTER> FFoo
Bar<ENTER>
>
>("f" means case-insensitive search; "F" case-sensitive.)
>
>Interactive editing commands are not code; self-documentation
>and comments are counterproductive; it's a motor skill.
>
>-- gil
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
