X-no-Archive:yes
Since I always write my ftp jobs to use command files, I did not know about
this looping problem with in line commands. But the reason I write my ftps
this way, with the user name and password in a netrc file, and the ftp
commands in another file, is to secure them from prying eyes. Back when this
still mattered under 55, I would run my ftp jobs under a non-IA user, only
allowing the IA (and non-BA) user to eXecute the job stream. The command
file would be read only for the BA user, in it's passworded home group, so
the BA user would not need the password, and no other regular user would
know it (nor would it be scripted anywhere). Basically, I wanted to make it
as hard as possible for anyone else to see or know quite what the ftp job
was doing on someone else's system, by snooping around on mine.

I could even name the command file the same as the job, but in another
group, and
!    RUN FTP.ARPA.SYS;INFO="OTHERSYS";STDIN=!HPJOBNAME.CONFIG
Then I could copy an existing job, edit the job card, and then only have to
create and secure the new command file.

Wirt wisely points out the need to code for failures. I like the ambiguity
of that, because sometimes, under certain circumstances, you probably WANT
the job to fail, either quietly or spectacularly (literally). What if it
simply cannot reach your AS/400? Do you still want it to keep trying every
two minutes, or do you want the job to stop / fail? If the latter, you
probably need documentation and procedures for who will know and notify
whom, and how the job will be restarted, and you probably want to test
FTPLASTERR after the ftp or endwhile. If the former, then while you may want
your ftp command file to EXITONERROR, you probably do not want your job to
abort. I have received calls in the wee hours about someone else's server
being down, and have had the satisfaction of being able to assure the caller
that our ftp job is going to happily wait ten minutes, and try again n
times. Recovery can be gratifying.

Gavin also asks some great questions about a job that streams itself, and
how you make sure that any such job does not pick up the wrong file, or the
right file at the wrong time. More has to be known about where the file is
coming from, and why it is going to this AS/400, and even what the
significance of two minutes is to this process. If Thomas Hoffmann cares to
post more of these details, I'm sure members of the list can ask some good
questions, and share experiences with similar processes.

Greg Stigers
http://www.cgiusa.com