[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ftp_get local file question



Scott,

I understand your frustration and I appologize.

I don't want to use the ibm client because it's too inflexable.  but that
inflexability contributes to its consistancy.

There is a definate need here for the app I'm writing and the ibm client
just isn't right for the job.  your apis have gotten me very close to my
goal.  it has been a lot tougher than I thought it would be, given the wide
range of variations i've run into.

I've been 90% there for a few weeks now, but I keep coming across 'the
little things' - things that are unique to one client, or another server,
that i didn't think about or wasn't aware of - that set me back - no fault
at all to your apis - only my lack of knowlege/experience with ftp.  If my
questions sometimes sound simplistic or incomplete, it's because i'm not
sure if it's not just something simple that i'm missing.

anyway, thanks for the help with code pages.  I think I get it now.  I also
tried etherial to sniff the ibm client over the network, but it didn't find
anything - probably a routing or firewall issue - maybe i'll try win/dos
ftp from my pc to see what it does with the GDG stuff.  the problem is that
my client that uses gdg is strictly ppp dial-up.  makes it hard to test.
plus, each time you download a file, it disappears and you can't download
it again, so you only get one chance a day to test.

I have very little to base this on, but I have a sneaking suspicion that
the initiating client does much of the (-x) work itself, rather than the
server.  I will probably just do a ftp_list, go to the end of the dataset
and count backwards to get the (-x) file i need.

just an fyi, since I sent you the code a couple weeks ago, i've fixed about
20 bugs, added or re-wrote a bunch of features, redesigned the job flow a
ton and have better replacement variable schemes and examples.  and I feel
like i've only just begun to make it right.

anyway, thanks again for your help.

rick