I have a customer using my Download Definition tool for SB+ who is reporting a strange thing (at least to me). When he kicks off a download (which is effectively a tight optimized READNEXT loop extracting data, formatting it, and writing it via WRITESEQ) it pegs a CPU - full on 100%. Maybe I spend too much time under a rock, but .... I have never seen a single Unidata session peg a CPU on AIX - until now.
We've run Unidata profiling to try to get a handle on the issue and nearly 70% of the time (from the profile.elapse) is being invested in the SB.EVAL.EXP subroutine being called from the tool. Of course, I have no access to the source code for SB.EVAL.EXP but I have seen where complex SB+ stacks can definitely impact the performance of the tool. Yet, in looking at the stacks that are being used, all of them in the test case are simple record extractions (i.e. R5 or R18,-1). @RECORD is loaded before the stacks are evaluated so there should be zero I/O being done in SB.EVAL.EXP and even if there was I/O, how could this one subroutine peg a CPU? -Kevin http://www.PrecisOnline.com _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
