Delete or Copy Flat File (B4700230) running very slowly

jimmymac

Reputable Poster
We are on E1 9.0, tools 9.1.4.7.

We use business function B4700230 to copy a flat file as part of some of our interface processing. We get a file from Concur for expenses that we process and create journal entries. In this process we copy the original text file form Concur to an archive location. Usually the file is around 9,000 KB and takes just a few minutes to copy. The current file is 15,000 KB and has been copying for several hours. Its copying but very slowly.

Any ideas from anyone why a file about 50 % larger than normal would take so long. Its still running and appears it will take about 6 hours to do a copy of this file using B4700230.

Or any ideas as to where to start looking? I've looked at JDE server manager but there appears to be nothing I can see to explain the slowness. All other aspects of JDE are running fine and normal. Coincidentally, if we look back to year ago, this large year end file form Concur also took a long time to run. So its almost like there is some size above which , this function does its copy functionality very slowly.
 
"Usually the file is around 9,000 KB and takes just a few minutes to copy ..."

I guess I want to know why it takes a few minutes to copy. It should take less than a second!
There's something wrong in your system configuration me-thinks!
 
You can try copy flat file with command bsfn, and compare times, if it takes minutes the problem the problem is in server. I'm agree with Larry_Jones, copy a file should be miliseconds not seconds or minutes.
 
Thanks for the input. The standard C function we are using B4700230 appears to be not actually doing a Copy but is reading a record from the target flat file and writing it to the new flat file, so its not as fast as just doing a copy. The entire interface in this case (which is for Concur expenses) usually take 10-15 minutes that includes two file copies and then several other steps (two table conversions and another JDE batch job to calculate offsets). How much of that typically is the file copies we are not sure because we've never had an issue with the performance of these interfaces to need to take a look.

We've done some testing today in our Test environment and getting similar results. When the first 'Copy' or call to B4700230 occurs, the output flat file shoots up to 5,000 KB or so, just just slows to about 150 KB per minute. Our network team is still researching but cannot see anything in particular that would be slowing it down.

Oracle's response was to not use the B4700230 but use B34A1030 Execute External Program and call a Copy command native to the platform. I understand their request but we are not looking to rewrite our processes when they have been running fine for years. Just need to find what has all of a sudden been slowing things done.

Thankfully most of our interface files are much smaller, 1 KB to 1,000 KB and are having no issue.
 
.... but use B34A1030 Execute External Program and call a Copy command native to the platform.

I was going to suggest this too, but I couldn't see what platform you are on. I've used this before on Citrix/Windows and used XCOPY copy commands happily enough.

Are you saying the first file works if a file is small (under 5mb)? If so then that's pointing at something in your platform, not E1
 
Back
Top