> -----Original Message-----
> From: Barry Lake [mailto:[log in to unmask]]
>
> At 10:36 AM -0800 2/25/00, [log in to unmask] wrote:
> >Thanks to various postings on this list I have a set of
> command files which [initiate PC transfers...]
> by the time R1
> >comes back with its RUN PCLINK, my pgm is already waiting
> for the next menu
> >selection.
>
> If you could make your menu driver do
>
>    :run ci.pub.sys;parm=2;info="xeq myscript"
>
> then, once your script finishes running, you will be left at the colon
> prompt, and the RUN PCLINK should work.

... and then the user has complete access to the HP, thus invalidating the
security and safety of the menu system!

[unless, perhaps, you set the script to be OPTION NOBREAK and include an
"exit/bye" command at the end, but I wouldn't fully trust such a solution]

The better solution, of course, is to have the menu system prompt for [and
validate] that the "command" passed back from the "client" is indeed a run
PCLINK[2].<location> command (there is both a "PCLINK" and a "PCLINK2" host
program, and nothing really precludes you from moving it to accounts &
groups other than "pub.sys"...)

If your menu program is, shall we say, "ultra generic", you probably cannot
do this without a major investment in your menu system.  An example of such
would be a configuration file that consists of prompts and programs to run,
probably with limited ;parm & ;info options.  If your menu is more
sophisticated, i.e., it emulates some of the command interpreter, you simply
need to alter the command(s) that are executed in response to a menu item to
include a "prompt for..." and either discard it or validate & use it as I've
indicated above.

Tom Emerson
Sr. Systems Analyst
NDC | e COMMERCE
[log in to unmask]
626-258-4309
626-350-3832 FAX