Re: FTP to fast -- MIDRANGE-L

Hi Roger

I suppose it depends on FTP behavior - once a transfer (PUT or GET) starts, it is pretty much an atomic operation, you can't do part of it, that I know of. Your and my suggestions are really for slowing down the overall process, with time in between each step. These might not do what the target system seems to need, as you say Laura will see how things go!

Cheers
Vern

On 2/2/2022 1:32 PM, Roger Harman wrote:

Since it's a sub-command in the FTP stream, my assumption (we know how that works out sometimes!) was that it would cause a "pause" between the other FTP commands in the script if you "inline" it in the appropriate spots.

Easy for Laura to test though.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Vern Hamberg via MIDRANGE-L
Sent: Wednesday, February 2, 2022 8:20 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Subject: Re: FTP to fast

Good point has Larry - if you use regular FTP with a script.

Scott's FTPAPI consists of separate functions for each step, so you can
put delays between each one - much more management is possible.

Cheers
Vern

On 2/2/2022 8:36 AM, Larry "DrFranken" Bolhuis wrote:

I don't think the DLYJOB would help because once you get to the FTP
command it's gonna blow through the commands in the very quickly.

One thing that might work:

Set up the FTP job with the INPUT file using a EOF Wait. Start the
INPUT file member with just thhe user ID and password. Then meter the
rows into the INPUT file, there DLYJOB will work between writes to the
member. FTP will sit and wait for rows to appear in the file thus
delaying the process as needed.

    - DrF

On 2/1/2022 10:14 PM, Roger Harman wrote:

I don't have access to a system to try this but the syscmd (or !)
subcommand might work. You could call a CL with a DLYJOB in it.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fi%2F7.4%3Ftopic%3Dssw_ibm_i_74%2Frzaiq%2Frzaiqsyscmd.htm&data=04%7C01%7C%7C9d1fd9e061c54e11e84908d9e667efc5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637794156356852073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X7CDvFwJoJGykHZXCIpVxqBeylxKIakn%2Bm3o9ipI4tI%3D&reserved=0

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Laura Ubelhor
Sent: Tuesday, February 1, 2022 6:01 PM
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: FTP to fast

Hello:
This is a first. We are working with a customer on an application
that we create files on IBM i and transfer to a mircrosoft server
using FTP. We've already asked and repeatedly been told FTP is the
only way we can send the files.
The job stopped working in December and it wasn't noticed until
sometime later the application was not completing. After researching
and testing and troubleshooting on the IBM i and checking out the
script............to no avail. Oddly the script ran fine when we ran
it manually but we could not get it to work through a submitted job
scheduled to run late at night. Everything was exactly the same for
the script used to FTP when we did it manually and when the job ran
as a scheduled job.
We finally were able to get some help on the microsoft server side
and the following was determined. Working with the networking and
server team to validate the following conclusions were reached.
They believe the reason the manual run works is because it was run slow.
The failure is that the server is placed into passive mode by IBM i.
And not enough is granted to get it out of PASV mode. They were able
to get the logs from a recent run from the FTP Server. It was
competing with a very large amount of other FTP traffic. They said
they cannot stress this enough we need to slow it down. Based on the
traffic from the FTP Logs and the Network capture. The IBM i is
jamming the data through. They asked the script be changed to slow
it down to fix the problem.
Following is the script used for the job
xx-de-ffm-FTPSXXXX xxxxxxxx
namefmt 1

lcd ..

lcd /Bxxxxxxx

cd /DataxxxxImport/PURCH_DlvTerm

put DlvTerm_031.txt

cd ..

cd /DataxxxxImport/PURCH_GoodsReceipt

mput GoodsReceipt_031*

cd ..

cd /DataxxxxImport/PURCH_Invoices

mput Invoices_031*

cd ..

cd /DataxxxxImport/PURCH_Item

put item_031.txt

cd ..

cd /DataxxxxImport/PURCH_PaymentTerm

put PaymentTerm_031.txt

cd ..

cd /DataxxxxImport/PURCH_PricesMaster

put PricesMaster_031.txt

cd ..

cd /DataxxxxImport/PURCH_SettlementDisc

put SettlementDisc_031.txt

cd ..

cd \DataxxxxImport\PURCH_Supplier

put Supplier_031.txt

quit

Here is the last log from when it ran in batch successfully

This is in the last GOOD FTP Log:

              look at next rcd~ > put DlvTerm_031.txt

          --now check for response

              look at next rcd~ 227 Entering Passive
Mode (10,101,1,10,0,100).

              look at next rcd~ 150 File status okay; about to open
data connection.

              look at next rcd~ 226 Closing data connection.
Transferred 252 bytes in 1 seconds. 0KB/second.

This is a first but does anyone have ideas how to so to speak slow
the job down. We've been told FTP is the only option.
Regards,Laura

Laura Ubelhor

President

Consultech Services, Inc.

Office: (248) 628-6800

ubelhor@xxxxxxxxxxxxx | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.consultechservicesinc.com%2F&data=04%7C01%7C%7C9d1fd9e061c54e11e84908d9e667efc5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637794156356852073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kYAPHu2Z1XqVS7Hnk5VU9uMNTqEd%2B5AQSo%2F0bVocqM0%3D&reserved=0