Paul asks:

> I have a client that has been using reflection to do file transfers.
However
>  the users that need to do this
>  then have a colon prompt logon, instead of going straight into a menu
> program.
>
>  What other ideas are there for doing this without giving out a colon prompt
>  access and yet remain
>  friendly enough, like the reflection file transfer?

As it occurs, I'm working on something that would probably do exactly what
you want -- and of course, with our superior business acumen, we're going to
give it away for free as part of the QCTerm project.

The program, as yet unnamed, will be a PC-based, independent FTP or HTTP
downloader program that will be able to be called in four different manners:
the first as a program invoked from within QCTerm's pull-down menus, and it
will look very much like Reflection's current file transfer screens. The
second method will be as a stand-alone program that can be invoked outside of
QCTerm (or any other program), and again look very much like Reflection's
screens. The third as a program that can be invoked from a script file, but
completely quietly download the specified files (with no visible screen). And
the fourth as a escape-driven sequence from within QCTerm, so that the host
application program can open up and quietly initiate file transfers, but
again with no visible screen, but with the added advantage that the currently
executing program can continue to operate without any form of interruption.

I've already created one such auxiliary program for QCTerm, named
FILEGATE.EXE (in a moment of nostalgia for the outgoing administration :-)
and it's working very well. I'm quite pleased with it.

FILEGATE is used with the van Gogh mode of QCTerm to download blobs (sound
and image files) from whatever server you specify. That server can be the
same HP3000 that you are currently connected to through telnet, or it can any
other machine that you choose, pretty much anywhere in the world. Moreover,
because FILEGATE uses FTP and HTTP, we're essentially "platform-agnostic", to
use the modern vernacular.

QCTerm controls FILEGATE through the use of a command file that consists of
several parts: (i) a session ID number, thus allowing multiple instances of
FILEGATE to be run simultaneously, (ii) the URL of the server and any
auxiliary information necessary to log on, (iii) a separator sequence, " |*|
", and (iv) the list of files to be downloaded. A pipe character is used in
this list to separate those files that are to be visibly downloaded and those
that are to be quietly downloaded, in background. The pipe can appear
anywhere in the list, at the beginning, end or middle. (Spaces are used as
the delimiters in these command files).

Examples of the command file are:

=========================================
HTTP example string:

   12345 http://aics-research.com/blobs |*| posix1.wav posix2.wav | posix3.wav

FTP example string:

   23456 ftp://aics-research.com/blobs user anonymous pass
[log in to unmask] |*| posix1.wav posix2.wav | posix3.wav

========================================

The new program will be essentially identical, except that we will have to
give provide a great deal more information in the command string (put vs.
get, PC target folder, binary vs. ascii vs. labelled files, etc.)

The question to you all is: Can any of you see any possible security problems
in such a program? If a remote user/hacker could get into your PC and
activate it -- or any other program -- he could download/upload a massive
number of files to or from your PC.

I truly doubt that there is such a way to enter a PC, set in a command file,
and then light a program. If it were possible, someone would have figured it
out by now. Nonetheless, I would be very interested in any comments anyone
might have.

FILEGATE is intrinsically safe. It only downloads files from a specified
server -- and it always places them into the c:\aics\cache folder. The
enhanced, full-file transfer version will be able to transfer in both
directions, to and from any directory on your PC. But this is in essence no
different than the capabilities that are present in the current MS-DOS FTP
client program that's on every PC now.

However, the expanded version should be quiet handy to use. You will be able
to bring it up and perform file transfers without ever having to actually log
on to a session on your HP3000. Or alternatively, you will be able to
initiate its execution from any client program you might have written. We'll
publish full specifications when we get it done (probably post-Philadelphia;
it's a low-priority project at the moment).

Wirt Atmar