# JD Edwards UBE Runtime Log Worksheet > Source: https://netray.co/tools/jde-ube-runtime-log-worksheet > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Record each UBE run with its version, records processed and runtime, and see throughput per second so slow versions stand out. ## Category oracle ## Erp Oracle JD Edwards EnterpriseOne ## Audience - JDE CNC administrator - JDE developer - Batch operations ## Tool **Kind:** worksheet **Mode:** editable **Columns:** #### UBE and version **Key:** job **Type:** text #### Server / queue **Key:** server **Type:** text #### Run date **Key:** run_date **Type:** date #### Records processed **Key:** records **Type:** number #### Runtime **Key:** minutes **Type:** number **Unit:** min #### Records per second **Key:** rps **Type:** number **Expr:** records / (minutes * 60) **Format:** decimal #### Result **Key:** result **Type:** select **Options:** - Done - Error - Killed #### Observation **Key:** note **Type:** text **Rows:** **Job:** R42800 XJDE0001 **Server:** ENT01 / QBATCH **Run date:** 2026-10-12 **Records:** 18400 **Minutes:** 22 **Result:** Done **Note:** Month end invoice print **Job:** R09801 XJDE0002 **Server:** ENT01 / QBATCH **Run date:** 2026-10-12 **Records:** 96000 **Minutes:** 41 **Result:** Done **Note:** Post of journal batch **Job:** R3482 XJDE0001 **Server:** ENT02 / MRPQ **Run date:** 2026-10-13 **Records:** 52000 **Minutes:** 118 **Result:** Done **Note:** Runs slower on Mondays **Job:** R42565 XJDE0003 **Server:** ENT01 / QBATCH **Run date:** 2026-10-14 **Records:** 7300 **Minutes:** 9 **Result:** Error **Note:** Failed on lock wait **Job:** R04572 ZJDE0001 **Server:** ENT02 / QBATCH **Run date:** 2026-10-15 **Records:** 24800 **Minutes:** 6 **Result:** Done **Note:** Address book extract **Totals:** #### Total records **Key:** records **Agg:** sum **Format:** integer #### Total runtime **Key:** minutes **Agg:** sum **Format:** minutes #### Slowest throughput (records per second) **Key:** rps **Agg:** min **Format:** decimal #### Runs logged **Key:** job **Agg:** count **Format:** integer **Summary:** #### Overall throughput (records per second) **Key:** overall_rps **Expr:** sum_records / (sum_minutes * 60) **Format:** decimal **Primary:** true #### Average runtime per run **Key:** avg_min **Expr:** sum_minutes / count **Format:** minutes **Notes:** Take records and runtime from your own Work With Submitted Jobs and report logs. Example rows are illustrative only. Compare the same version across days rather than different reports against each other. ## Content **Intro:** Batch performance complaints in JD Edwards are usually vague: the job is slow. A short runtime log turns that into numbers you can compare, so you can tell if a version slowed down, a queue is overloaded, or the data volume simply grew. **Sections:** #### How to use the worksheet **Body:** Log every notable run of a UBE and version: the server and queue, the date, the records processed and the runtime in minutes. The worksheet calculates records per second for each row and the overall throughput at the bottom. Add a short observation such as month end, lock wait or large batch. Export to Excel to sort by throughput or filter by queue. **Bullets:** - Take runtimes from Work With Submitted Jobs or the job log. - Use a consistent record count source, such as the report summary. - Log failures too, with a note on the cause. #### Reading the numbers **Body:** Throughput is records divided by seconds. It is a rough comparison tool, not a precise benchmark. If the same version drops sharply between two dates with similar volumes, look for locking, a changed index, a database statistics issue or competing jobs on the same queue. If throughput is steady but runtime grew, volume grew. Compare like with like: a posting UBE and a print UBE do very different work per record. #### Where the time usually goes **Body:** In batch runs the time is commonly spent in database reads and writes, waiting on locks, or in business functions called per record. Logic or data selection changes in a processing option or data selection can change the number of records read without changing the records printed. Note the processing option template and data selection used for every logged run so results stay comparable. #### Common mistakes **Body:** Teams compare a run that was alone on the queue with one that shared it with a dozen jobs. They log wall-clock time that includes waiting in queue, not the execution time. They forget to record the version. Keep the log short and consistent rather than detailed and abandoned. **Cta:** If you want runtime trends pulled automatically from your job history and asked in plain language, Netray can show how that works on your own data. **Faq:** #### Where do I find runtime for a UBE? **Answer:** Work With Submitted Jobs shows submitted, start and end times for each job, and the job log and report footers give more detail. Use the execution start and end, not the time the job spent waiting in the queue. #### Is records per second a reliable benchmark? **Answer:** It is useful for comparing the same version over time, not for comparing different reports. Record size, joins, business functions and I/O differ greatly between UBEs, so use it as a trend signal rather than a score. #### How many runs should I log? **Answer:** Start with the jobs people complain about and your month end critical path. Five or six runs of each give a baseline. Add more only if they help you make a decision. #### Can I export the log? **Answer:** Yes. Export to Excel, CSV or PDF from the tool. Excel is handy for pivoting by queue, server or version once you have a few weeks of data. ## Search terms jde ube performance tracking, jd edwards batch job runtime log, jde ube runtime excel, jde slow ube analysis, jde submitted jobs performance, jde batch window tuning, jde ube throughput records per second --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json