Hi, I may be wrong, but is not that effect of file handles pooling? As far as I remember jBASE keeps physically not more than X (say 1000) files open. Closing a handle / file means loosing its lock, right? (not 100% wheter I am right)
Kind regards Pawel Dnia 17-08-2011 o godz. 6:45 Mark Hogden napisał(a): > Just to add that hammering the lock table (for example doing thousands > of file opens in a short period of time) under 5.2.x on Windows 'seems' > to cause locking to lose its way, regardless of file type. > > -----Original Message----- > From: jbase@googlegroups.com [mailto:jbase@googlegroups.com] On Behalf > Of adrian > Sent: Monday, August 15, 2011 4:54 PM > To: jBASE > Subject: Re: jbase problems show-items-locks > > > Jim, > > Thanks for your reply, what is happening is that when these blank keys > locks show in show-item-locks the throughput of the system is hit bady. > Also noticed that the more locks a transaction makes then the blank keys > start appearing. > > Is is then the problem that the JR files group lock? > > Never seen blank keys before unless there is a bug in the code, but this > is happening for almost all T24 applications (high volume) loads, with > more than 4 file locks. > > We are using mostly JR type files with some J4 files. > > AA > > > On Aug 15, 1:31 pm, Jim Idle <j...@temporal-wave.com> wrote: > > Nice idea, but I seem to remember that in fact I/we had to put this > > back in specifically for T24. All the things you mention, and anything > > that you could mention are unfortunately relied upon implicitly by > > almost all software. If I had a dollar for all the Universe bugs we > > had to recreate so that we could port things, then there would be a run > on dollar bills. > > > > The system is what it is, and there is no changing it. This is not the > > jBASE guys saying this, this is all the users. > > > > Jim > > > > > > > > > -----Original Message----- > > > From: jbase@googlegroups.com [mailto:jbase@googlegroups.com] On > > > Behalf Of Pawel (privately) > > > Sent: Monday, August 15, 2011 12:56 PM > > > To: jbase@googlegroups.com > > > Subject: RE: RE: jbase problems show-items-locks > > > > > Hi, > > > > > I hope that I will finally see an (environment variable?) option in > > > jBASE, which will cause jBASE to abort when empty id is used in > > > database operation. All cases with an empty id I have met so far > > > were caused by software bugs. Moreover they were relatively hard to > > > track - usually it was complex flow to recreate problem. I do not > > > see any reason in keeping 'empty id functionality' available for T24. > > > It would be nice if jBASE team could go forward and throw away some > > > unnecessary, 'old days' things :) > > > > > Another issue that can be caused by buggy software is to put > > > field/value/subvalue markers. Some jBASE commands will be later > > > confused. jBASE gurus: throw these possibilities away please! > > > > > Kind regards > > > Pawel > > > > > Dnia 15-08-2011 o godz. 20:29 Jim Idle napisał(a): > > > > An empty record key is just a key without any characters. It is > > > > somewhat pointless, but must be supported as people inventing > > > > their > > > own 'security' > > > > used it a lot in the old days of Pick. > > > > > > Jim > > > > > > > -----Original Message----- > > > > > From: jbase@googlegroups.com [mailto:jbase@googlegroups.com] On > > > > > Behalf Of VK > > > > > Sent: Monday, August 15, 2011 7:56 AM > > > > > To: jBASE > > > > > Subject: Re: jbase problems show-items-locks > > > > > > > ... and don't forget MATREADU (though used in less number of > > > cases)... > > > > > > > BTW, it was always interesting to me - what's the idea of having > > > > > lock with empty record key? Does it have any sense from DBMS > > > > > point > > > of view? > > > > > > > VK > > > > > > > On Aug 14, 3:46 am, adrian <ar_atkin...@yahoo.com> wrote: > > > > > > With Temenos we have found there is a problem at the Jbase > > > > > > level as > > > > > we > > > > > > have patched the F.READU program and there were no NULL > > > > > > records being delivered here. > > > > > > The null problem is seen more when there are a lots of locks > > > > > happening > > > > > > for a application, and AA and AZ have this so it is easier to > > > spot. > > > > > > > > The F.OFS.REQUEST.DETAIL on some of out loads takes this file > > > > > > to 15gb and bigger. > > > > > > > > Regards and Thanks > > > > > > AA > > > > > > > > On Aug 11, 6:58 am, VK <kzm...@yahoo.com> wrote: > > > > > > > > > Hi, > > > > > > > > > F_JOB_LIST looks ok... 2 files with no IDs are F_LANGUAGE > > > > > > > for one session and FBNK_CUSTOMER_ROLE for another (though > > > > > > > it looks not being DM-related - maybe the problem is here? > > > > > > > both use CUSTOMER > > > > > file)... > > > > > > > > > Might be that some core code issued F.READU without > > > > > > > supplying > > > ID > > > > > (or > > > > > > > supplying a COMMON variable that contains an empty string). > > > > > > > Put > > > > > that > > > > > > > query to Temenos helpdesk. > > > > > > > > > What's the task is BTW? Update of which fields in CUSTOMER? > > > > > > > Might > > > > > be > > > > > > > an easier solution to that... > > > > > > > > > Another note - non-secure is really not secure :(( Consider > > > > > > > using secure mode (and pay something in performance) or J4. > > > > > > > > > Yet another note... is DM something called "migration tool"? > > > > > > > > > And - your OFS.REQUEST.DETAIL is distributed? Just curious why. > > > > > > > Accumulating over 2Gb a day? > > > > > > > > > VK > > > > > > > > > On Aug 10, 7:45 pm, adrian <ar_atkin...@yahoo.com> wrote: > > > > > > > > > > We are using 10 threads at the moments > > > > > > > > > > we are using JR type out of the box from Temenos. (non- > > > secure) > > > > > > > > > > we are using DM.SERVICE.DATA.FILE which we are using on a > > > > > > > > RAM > > > > > drive. > > > > > > > > > > as you can see below in the show-item-locks you can see > > > > > > > > blank > > > > > keys. > > > > > > > > > > 31 9358 ../bnk.data/st/ FBNK_CUSTOMER_CHARGE > > > > > > > > 5383596 > > > > > > > > 0x57a7c41c,W --- > > > > > > > > 31 9358 ../bnk.data/st/ FBNK_CUSTOMER_ROLE > > > > > > > > 0x02300000,W --- > > > > > > > > 31 9358 ../bnk.data/st/ FBNK_RELATION_CUSTOMER > > > > > > > > 5383596 > > > > > > > > 0x57a7c41c,W --- > > > > > > > > 31 9358 ../bnk.data/st/ FBNK_RELATION_CUSTOMER > > > > > > > > 11561555 > > > > > > > > 0x5e90b3b0,W --- > > > > > > > > 31 9358 ../bnk.data/st/ FBNK_CUSTOMER#NAU > > > > > > > > 5383596 > > > > > > > > 0x57a7c41c,W > > > > > > > > > > 33 9367 ../bnk.data/of/ > > > > > > > > F_OFS_REQUEST_DETAIL_06 > > > > > > > > MBDM112090115838227.05 > > > > > > > > 0x31fc7d36,W --- > > > > > > > > 33 9367 ../bnk.data/eb/ F_DM_SERVICE_DATA_FILE > > > > > > > > CCS.DM.CUSTOMER.MEMA-20110810037483638476 > > > > > > > > 0x59b0e064,W --- > > > > > > > > 33 9367 ../bnk.data/eb/ > > > > > > > > F_JOB_LIST_3 > > > > > > > > 1139 > > > > > > > > 0x6883ccaf,W --- > > > > > > > > 34 9371 ../bnk.data/eb/ F_LANGUAGE > > > > > 0x0000001c,R > > > > > > > > --- > > > > > > > > 34 9371 ../bnk.data/st/ FBNK_CUSTOMER#NAU > > > > > > > > 4872036 > > > > > > > > 0x04b9c9ed,W --- > > > > > > > > 34 9371 ../bnk.data/of/ > > > > > > > > F_OFS_REQUEST_DETAIL_08 > > > > > > > > MBDM112090521738237.01 > > > > > > > > 0x5c4e0da1,W --- > > > > > > > > 34 9371 ../bnk.data/eb/ F_DM_SERVICE_DATA_FILE > > > > > > > > CCS.DM.CUSTOMER.MEMA-20110810037483537290 > > > > > > > > 0x0f29a5e6,W --- > > > > > > > > 34 9371 ../bnk.data/eb/ > > > > > > > > F_JOB_LIST_3 > > > > > > > > 250 > > > > > > > > 0x7b754110,W --- > > > > > > > > > > AA > > > > > > > > > > yep , onlive it will be a one off but now its run once > > > > > > > > every two weeks. > > > > > > > > > > On Aug 10, 7:16 am, VK <kzm...@yahoo.com> wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > Clarify several things please: > > > > > > > > > > > > many threads say to update customer > > > > > > > > > > > How many? Which method is used? Service > > > > > > > > > OFS.MESSAGE.SERVICE I > > > > > presume? > > > > > > > > > > > > RECORDKEY is blank in the locking tables > > > > > > > > > > > Which tables exactly? F.LOCKING or F.JOB.LIST.n? > > > > > > > > > > > > JR type files database > > > > > > > > > > > Secure updates or non-secure? > > > > > > > > > > > Last but not least - updating 1m customers looks like a > > > one- > > > > > time > > > > > > > > > task, not a regular one, isn't it? > > > > > > > > > > > VK > > > > > > > > > > > On Aug 6, 5:39 am, adrian <ar_atkin...@yahoo.com> wrote: > > > > > > > > > > > > When running many threads say to update customer > > > > > > > > > > (1,000.000) some of the tsa's show SLEEP in the mw42 > > > view. > > > > > > > > > > > > Looking at the show-items-locks we are see many times > > > > > > > > > > lately the RECORDKEY is blank in the locking tables, > > > > > > > > > > when this is happening the agents are only processing > > > > > > > > > > 120 per minute while if we see no blank keys then we > > > > > > > > > > can process > > > > > > > > > > 20,000 + a > > > > > minute. > > > > > > > > > > > > Have we a problem with our Jbase version or is this > > > normal > > > > > > > > > > to see records in the lock table with blanks , I must > > > > > > > > > > say i have never seen this over the pass years. > > > > > > > > > > > > We are not using the jbase locking but the UNIX > > > > > > > > > > locking (set at > > > > > > > > > > 24,000) on a HP box as the jDLS was causing problems. > > > > > > > > > > The > > > > > unix > > > > > > > > > > locking has been running fine for over a month now. > > > > > > > > > > > > Could somebody knowing Jbase explain many thanks. > > > > > > > > > > > > Sorry we are using JR type files database and R10 with > > > > > > > > > > many > > > > > patches. > > > > > > > > > > > > System Information > > > > > > > > > > ================== > > > > > > > > > > > > System : HP-UX vic-samt B.11.31.U > > > > > > > > > > ia64 UNIX User : aatkinso (uid 187, > > > euid > > > > > > > > > > 187) > > > > > Tty > > > > > > > > > > name : /dev/pts/0 > > > > > Time > > > > > > > > > > : Fri Aug 5 20:31:32 2011 > > > > > > > > > > > > Environment > > > > > > > > > > =========== > > > > > > > > > > > > JBCPORTNO : Not Set > > > > > TAFC_HOME > > > > > > > > > > : '/app/tafc/r10SP8/R10' > > > > > > > > > > JBCGLOBALDIR : '/app/tafc/r10SP8/R10' > > > > > > > > > > WARNING: JBCDATADIR is not set, Default > > > > > '/app/tafc/r10SP8/R10/ > > > > > > > > > > jbase_data' > > > > > > > > > > WARNING: JBCDATADIR is subdirectory of JBCGLOBALDIR > > > > > HOME > > > > > > > > > > : '/app/t24/dm5/bnk.run' > > > > > > > > > > JEDIFILEPATH : '/app/t24/dm5/bnk.run' > > > > > > > > > > JEDIFILENAME_MD : '/app/t24/dm5/bnk.run/VOC' > > > > > > > > > > JEDIFILENAME_SYSTEM : > > > '/app/t24/dm5/bnk.run/SYSTEM' > > > > > > > > > > RELEASE Information : Major 10.0 , Minor 0.8 , > > > > > Patch > > > > > > > > > > (Change > > > > > > > > > > 92702) > > > > > > > > > > Spooler dir (JBCSPOOLERDIR) : '/usr/spool/jspooler' > > > > > > > > > > JBCEMULATE : 'prime' > > > > > > > > > > Object path (JBCOBJECTLIST) : > > > > > > > > > > '/app/t24/dm5/bnk.run/ccslib:/app/t24/ > > > > > > > dm5/bnk.run/GR0800004lib:/app/t24/dm5/bnk.run/t24lib:/app/t24/ > > > > > > > > > > dm5/ > > > > > > > bnk.run/GR0800005lib:/app/t24/dm5/bnk.run/GR0800006lib:/app/t2 > > > > > > > > > > 4/dm5/ > > > > > > > bnk.run/radlib:/app/t24/dm5/bnk.run/cardlib:/app/t24/dm5/bnk.r > > > > > > > > > > un/ > > > > ... > > > > read more Âť- Hide quoted text - > > > > - Show quoted text - -- 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 jBASE@googlegroups.com To unsubscribe, send email to jbase-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
