Jeff writes:
> While this topic is fresh, does anyone care to propose a
> syntax for a new CI command, or an extension to the INPUT
> command (and/or input function) or a new CI function??

A CI function seems like perhaps a logical place to put this, since it
returns information.  Something like an "ASKOP" or "ASKOPERATOR" or
"INPUTOP" function that takes a question parameter and perhaps something to
indicate whether the request is for a yes/no answer, a string, etc.  You
could add this stuff to the existing INPUT function, but the parameters are
positional which would make the result somewhat ugly.  You'd also need some
convention for reporting errors and timeouts to the user (maybe the existing
INPUT function already addresses this).

On another hand, there is the :PAUSE command which has already been enhanced
to wait for a job to complete, so adding the ability to wait for an operator
request might make some sense (though "PAUSE" isn't the most likely place to
look if you're searching for this functionality).

Another option would be to add a new source option to the :INPUT command,
something like

:INPUT myvar;WAIT=600;PROMPT="OK to CONTINUE?";FROMOPERATOR

If you're going to enhance :INPUT, it would be nice to add ;FROMFILE= and
;RECNO= and maybe even ;FROMTCP= as long as you're at it :-)

> Should there be a timeout?

A timeout would be a nice option to have, since you could implement much
more intelligence in a job stream, i.e. after a timeout it could ask again,
invoke a program to dial a pager, etc.

> Should there be some basic cursor control/memory lock ability?

I would say probably not anything more than what :TELLOP/PRINTOP[REPLY]
allow today (i.e. nothing, or simple display enhancements only).

G.