Hi Mike, Hi Jim, I more or less understood, which kind of workaround Jim is suggesting. Problem is officially reported via CSHD and we are waiting. Nothing is confirmed, it happened many times that I was mistaken or made wrong assumptions/suggestions. I just wonder now how it can happen that we did not add new environments, neither release significant changes to the software (as far as I know) and memory finally run out. Perhaps growing data volumes can explain that? We regularly refresh test areas with LIVE system. So SSELECTs are launched on bigger and bigger files.
We are running T24 R06004 with many patches installed. Bank did not decide to install T24 Service Packs and it was in my opinion bad decision to me. So it happens that we are discovering already discovered and patched things, which is not funny at all :( 1. SSELECTs are performed by core and (unfortunately) local developments. Select I have shown (on watson) was done on FBNK.ACCOUNT.DEBIT.INT table. It is regular J4, not distributed file. We tried SSELECTs on few tables and effect was the same. 2. I generally agree, but your statement is true only when you do not use Oracle driver. I think that SELECT/READNEXT combinations should be avoided. Perhaps in the future Temenos will optimize SELECT <file> / SSELECT <file> and getting keys on jBASE will be so fast as on Oracle? I am not an expert, but I belive that they have field to improvements and it will be easier to do something to tune commands like SELECT than to tune internal SELECT/READNEXT. Perhaps in jBASE 6 SELECT on distributed file will launch multiple threads and partfiles will be scanned in parallel? It is just a stupid example, because I do not expect such improvements (who SELECTs distributed files?) By the way: we do not run on Oracle, but would like to keep portability. 3. Which kinds of memory issues? Either memory is correctly retained or not. We try not to do stupid things and use multiagent jobs as much as we can. We try not to create large transactions and find old local jobs that do. I personally think that memory must be somehow given back even if 1 of the jobs is stupid. Why job #2 is limited by previously executed, stupid job? I expect that if job #1 allocates 300 MB, then job #2 will be executed with (more or less) same initial memory utilization. 4. R06, I have seen that. Did they introduce that because memory leaked or internal SELECT is faster? I am joking of course. We did not test SELECT much, because we seen that memory utilization during COB increases after SSELECTs are run. Perhaps SELECT leaks also something. 5. ? Hmmm... You need to first collect all keys and store them in memory somehow, then to sort them with some algorithm, right? Sorting process may require more memory than just size of the keys, but this memory should be given back to process once SSELECT is completed. I think that it is not (fully?) in jBASE 4.1.5.17. Let's leave this subject for confirmation :) As I said in the begining I was mistaken many times. Kind regards Pawel Dnia 6-02-2009 o godz. 1:47 mike ryder napisał(a): > Hi Pawel, > > I know from previous posts that this is T24 related. > > You don't state which T24 release or on which table you are doing the > select or even if this is Temenos core code or your own local code. > > The reason why this may be significant is as follows: > > 1. SSELECT on SECURITY related tables can cause a problem. I have seen > such on SECURITY.POSITION. It occurs because the dictionary says that > the ID is right justified in 35 spaces and all of the keys take up 35 > characters and you run out of memory. Changing the dictionary to left > justified solves the problem. > > 2. If this is local dev, then doing an internal select can be much > faster. Where you expect to retrieve more than 50% of the keys and the > condition is based on the key, then an internal select with code will > be much faster and not hog the memory. > > 3. In local dev, many people try to do all of the processing in one > job when it would be more performant to select in one agent process > and process the keys in another. As an addendum to this, if you do > humongous processing in a job with transaction turned on all sorts of > memory issues occur. > > 4. The selection operation used by EB.READLIST has changed in later > releases (R6 or maybe R7) where internal select is used if the select > statement is called without parameters > > 5. I believe that SSELECT can be called as an internal selection > rather than an external selection which means that all of the keys are > not require to be stored before they can be processed/ > > Hope this is of interest > Mike ---------------------------------------------------- Najlepsi skoczkowie z Polski na zawodach w Wiśle i Szczyrku musisz tam być razem z nami! Kliknij: http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fnarta.html&sid=633 --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
