Program slow running

jdewannab

Active Member
List,
I have created a table conversion to convert a oneworld custom file to F4072 (Advance Pricing) We have well over 5 million records to process and in 1 day it has only processed 400,000 records.

Does anyone have any idea on how to speed this up? Is a fetch faster than a business function? Would it be faster in a report than table conversion?

This is what my program is doing besides straight maps.
OW Custom File F4072L
OW Table Conversion F89574072L
OW File (Straight Insert) F89574072L

I fetch to F0101 with my 2nd item to get my item shortid

Call F0002 Get Next Adjustment KeyID
Function name F0002GetNextAdjustmentKeyID
Source Module B4500070
I do not parm anything in, I just have the program pass me the mnAdjustmentKeyId

I also use FormatDateFromDMY (business FUnction)
Function Name B41B0470
Source Module B41B0470

Any help will be greatly appreciated.

XE, Enterprise AS/400, Windows NT
Thanks,
 

Christian Audet

Moderator
Staff member
Hi
I assume that it's running locally, what type of machine do you have to run it ?

Christian Audet



Implementing B7333 (Xe) SP14.1, SQL
(Support B732, B7331 and B7332)
 

ka4niv

Active Member
We had a similar problem with a payroll calculation job - out of
177,000 records, the job running on an AS/400 ran for a week
and still only processed 60,000 records. Someone wrote an
RPG program to do the same thing and it ran in just over 2
minutes.

Another job to run was calculated to run over a month. Don't
know what to do with that one.

XE, Enterprise AS/400 S/20, Deployment NT, Citrix, Formscape

Went live with financials 5/1, Purchasing 7/9, looking for everything
to be live 8/6, (except maybe payroll?)
 

tom_brown

Active Member
Have you investigated which parts of the code are running particularly
slowly? You can do this by running a very small data set(say only input 5
records), with debug logging switched on(then run the UBE locally). Then
trawl through your jdedebug.log after the run, and see if any single
operation is taking more than a second or two - , if so then that operation
will most likely be the cause of the massive slowdown when run over huge
data sets.

I tried this with the batch invoice processor(R03B11Z1I), and found that
simply by creating a new index I could make the program run 10 times
faster...

Regards

Tom Brown
 

David Robertson

Reputable Poster
Re: RE: Program slow running

A good point about Tom's suggestion... make sure the debug logs are all turned off and logging turned to it's lowest setting for the full run, as these will slow it down a lot, and create huge log files.

For this volume of data, I would try to run it on the most powerful machine available, which is probably your Enterprise server. Being on the same machine as the database would also help.
 

husni

Well Known Member
We faced a similar problem while converting F0911 table from DB2 to SQL7. It took 2 days to copy 2 million records. What we did was, dropped the table from JDE_PRODUCTION and re-created the file and indexes from Oneworld. It copied all the records in 8 - 10 hrs.
 

Larry_Jones

Legendary Poster
WannaBee,

Try replacing the call to F0002 Get Next Adjustment KeyID with just a simple increment (keep your own counter and increment) then update the F0002 table when the job ends (manually or programmatically). That should cut out a large part of your processing.

regards,


Larry Jones
ljones@wagstaff.com
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials
 

dschlieder

Well Known Member
Sadly I have found Table Conversion UBEs to be slower than molasses in January! And too many problems.

I used to have over 20 TC UBEs running every night pulling data out of JDE. For a number of reasons, I re-wrote every one of them as a regular UBE because of one issue or another with TC UBEs, of course having to code the INSERT for each row into the target table.

As it turns out, EVERY one of the UBEs I re-wrote ran considerably FASTER than the TC version of it.
 

David Robertson

Reputable Poster
Table Converter's are definitely slower than UBE's, but then they really work differently. For importing files into JDE, they are still one of the best options, just keep them simple, mapping data into a custom JDE table, then run a UBE over that with any more complicated logic.

For Exporting from JDE, use a normal UBE, and use the supplied business functions to write to the flat files as needed, the same as JDE does. They don't use TC's for exporting.

The idea of updating F0002 manually is good if you can be sure of integrity.
 
Top