UBEs taking longer on Server than Locally


We have certain UBEs that run faster locally than on the enterprise server. After some testing here is what I have discovered:

Standard JDE reports (nonfinancial) run about 2 times faster on the Enterprise.
Standard JDE Financial reports run about the same or a little faster on the Enterprise than locally.
Custom JDE Financial reports run about the same time locally and on the Enterprise.
Custom JDE Financial Row reports run about 2 slower on the Enterprise than locally.

I am curious to know if anyone else out there has problems with performance and Row reports. JDE has a SAR about the performance being slow with Row reporting but it says nothing about poorer performance on the enterprise. I could be way off that this is only happening for Row reports as I have only tested a handful of reports in general. If anyone has any ideas of other reasons why some jobs take longer on the server than on the client, please let me know.

Sun Solaris 6500 (12x12)
40 active users
Oracle 8i


Well Known Member
There are problems with Row reports we have created row reports that just
plain die because they are so big, call JDE and ask if there are any fixes;
I think not.

Scott B. Whipple
Technical Consultant
5300 DTC Parkway Blvd. Suite 430
Englewood, CO. 8011
303-740-5500 Work
303-884-1405 Cell


Was there ever a resolution to this issue? We are having the same type of problem, with the exception that it affects more than row reports. Our Sun V880s should be able to run a job much faster than a windows fat client.

Thanks for any help you can offer.
Steve Acosta


Active Member
We really never found a great resolution. We went up a service pack (to
SP17.1) at the time and that seemed to help some. The processing time
changed so that the fat client and sun box processed in about the same time
but that was the best we got it. We only had this problem with row reports

Sorry I am not more help!

<steve.acosta@martinma To: mschroed@generalgrowth.com
rietta.com> cc:
Sent by: Subject: Re: UBEs taking longer on Server than Locally

02/04/03 04:38 PM
Please respond to

sacosta replied to your post at the site: .

Was there ever a resolution to this issue? We are having the same type of
problem, with the exception that it affects more than row reports. Our Sun
V880s should be able to run a job much faster than a windows fat client.

Thanks for any help you can offer.
Steve Acosta


The information contained in this e-mail message may be privileged, confidential,
and protected from disclosure. If you are not the intended recipient, any further
disclosure, use, dissemination, distribution, or copying of this message or any
attachment is strictly prohibited. Unauthorized interception or disclosure of this
e-mail violates federal criminal law. If you think that you have received this
e-mail message in error, please delete it and notify the sender immediately.



XE SP17.1 Oracle SUN
Discover how to build no-code data integrations and business process automations.


Legendary Poster
Why should a SUN V880 run a job faster than a desktop ?

What processor does your V880 have ? What processor is in your desktop ?

I believe you probably have 500MHz Ultrasparc IIe processors in your V880 and your desktop is running, say, a P4 2.6GHz processor.

The speed difference between the processors - like for like - is dramatic. The RISC Ultrasparc is a little less efficient than the CISC Intel P4 when it comes to processing OneWorld UBE's - and the speed of the bus - almost 5 times - is also huge. Now, processor speed isn't everything, but when you're looking at a CPU bound procedure, its the vital factor.

Remember, it doesn't matter HOW many CPU's you have in your sun - as far as oneworld is concerned, its a single threaded procedure that sits on one processor....

Perform a speed test amongst the top of the range machines - run a simple UBE through each of the platforms and look at how long it takes to perform. I'll put money on the fact that Sun is likely to come last. Then run, say, 20,000 UBE's through the servers. Because the top Sun has almost 3 times the number of processors compared to its bretheren, its likely to be amongst the fastest - if not finish first.

Sun boxes are great database servers, awesome websphere servers and phenomenal scalable machines - but when it comes down to pure speed ? They certainly lag behind the curve. Remember, those UltraSparc processors are always going to be behind the curve compared to dedicated processor manufacturers.

Hope that helps !


Active Member
I am experiencing same problem on JDE Financial Row Report and our income statements took 20 minutes to run locally but It will took 1.5 hours on IBM AS400. JDE just has no clue on my problem. David


VIP Member
Just a shot in the dark, but this happened to me once...same symptom, run
the UBE locally and it speeds through, run it on the server, and it
drags. In this instance there was a problem with the table spec on the
server. I identified the tables the UBE was accessing and built an
update package with the tables and deployed it to the server. In this
instance, it solved the problem. My thinking was perhaps something was
corrupt with the table or index information in the spec file on the

I'm sure it's something else, but just wanted to throw that one out.

On Wed, 5 Feb 2003 17:05:17 -0800 (PST) dhsieh <dhsieh@haskel.com>

Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com


Well Known Member
Have you compared comparative debug logs from jobs running locally and on the
enterprise server? They will show you the time taken to execute each
component of the batch process. Specifically with row reports, I remember an
issue in b732 with regards to the order of the data selection impacting on
the performance of the reports.
Or then again, it could just be because it's an AS400 ;-)
Kieran Fitzgerald


You may want to goto the Knowledge Garden and look at document OTI-01-0064. It specifically addresses slow performance of Row reports on an AS/400


We had the same problem with our Sun server once. I know this sounds dumb, but the problem turned out to be the battery in the Sun box had expired and was gradually slowing down over time. By expired I mean that the expiration date had past, not that the battery had died. When the battery was replaced everything sped up again.


Legendary Poster

You battery went dead ? Surely the Unix admin didn't forget to wind up the machine ?

I wonder what the shelf life of solaris really is then...

LOL - I think you've been wound up yourself !


Active Member
Hi Jon,

You state in your post that the UBE is bound to one processor on the Sun server - is this true for NT servers also? If I add on an NT application server to our environment - am I limited to the number of job queues I can put on that box by the number of processors it has?



Legendary Poster
Hi Melissa

No - you got it the wrong way around

One UBE = One Process which runs on One Processor

Multiple queues would allow multiple UBE's to run in parallel, hence take advantage of multi-processor machines. The more queues, the more processors would be used. The more partitioned your data selection (together with more UBE's), the faster your procedure.

For example. Let us suppose that you have a Sun Solaris machine (appserver) with 64 processors, and in this example, network is 0 latency (impossible) with infinite bandwidth, and the speed of data retrieval on the database server is infinitely fast (also impossible).

If I send a GL post process to this application server for my company (with 64 branches) then it will take t hours to complete and will only use 1.6% CPU utilization (one of the 64 processors).

However, if I perform a GL post by partitioning the version by MCU - and create 64 versions and submit these together - then it will take t/64 hours to complete (providing each branch had the same amount of data which is unlikely - otherwise the total process would only take as long as the largest branch).

Now of course, there is going to be some database locking as the process runs - therefore not exactly providing you with a linear scale, but the idea is sound, and the reality is approximately (t/64)*2 - which is still much better !

For NT this is the same - if you only submit one UBE, it will only utilize one processor - though NT Task manager will incorrectly display 1/n utilization across all processors where n=# of processors.

Remember - the answer here is if you only had one queue configured. Set up multiple queues and USE them, and you'll use the CPU's in the machine.

Lastly, as Kara mentioned, the rule of thumb is 2 UBE Queues actively running per processor. This is to take advantage of the cpu's while the UBE's "sleep" during processing a batch run (for latency, bandwidth and DB server waits) - so in our example, I would size up a 32 processor Sun box to handle 64 branches rather than a 64 way since there wouldn't be much of a payoff for twice the # of processors.

Hope that helps.