X-no-Archive:yes
Wirt's approach is exactly what I would recommend.

There is however one "gotcha" when ftping a file to a UNIX or NT system,
albeit a potentially very small risk, depending on file size and throughput.
The file is visible on the 9000 while still being written or sent via ftp.
This is not a problem sending to the 3000, or to for instance an IBM (or
compatible) mainframes, because the file would not be visible to any other
process until after it has been completely transmitted. On the 3000, ftp
files are in the temporary domain, until ftp is through receiving them. When
sending to a UNIX or NT system, an apparently popular solution is to send
the file under one name (such as the name on the sending system, assuming it
will be different on the receiving system, or the target name without an
"extension"), and then, after the send, rename the file to its proper target
filename. A "gotcha" with this approach, on slower NT systems, is that NT
needs some time to finish writing its buffers to disk after ftp finishes. I
have no idea if this is an issue on a 9000. For this, we inserted a :PAUSE n
between the send and the rename.

How small or how large is this risk? Divide the check interval by the
average time it takes to send the file. If you check for the file every 300
seconds, and it takes two seconds to send the file, then your risk is one in
one hundred fifty. Stated differently, if you run this 150 times, then you
have essentially a 100% risk that your watching job will detect the file
while it is still being sent, one time over the 150 runs. Now, since some
time elapses between the detection of the file and the execution of the rest
of the watch job, this reduces the risk by at least that interval. But no
matter how small this risk works out to be (if you only run this job once a
month, check for the file once an hour, and the file takes one second to
send, this would happen once in three hundred years), it's probably worth
avoiding the risk by doing the rename.

An alternative solution would be to use rsh or remsh on the 3000 to initiate
the update process on the 9000. But this requires that you run the remote
shell service on the 9000. If you are not doing so, then doing so may not be
an option, and does create one more security risk. So does having a script
or job on your 3000 which contains a valid user name and password for your
9000. These can be avoided for the ftp jobs by using netrc files; I am not
sure if rsh can use netrc to avoid that risk. The watcher job entirely
avoids this security risk.

Greg Stigers
http://www.cgiusa.com

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *