In the small amount of testing I have done, the JR files are not very good -
you might try going back to J4 files and using FASTSCAN (see earlier email).
I suspect that you are in fact seeing 'group' locks, which are taken on the
hash bucket to prevent the 'group' being changed while in use. FASTSCAN
allows you to avoid taking the lock, but you must require that there are no
updates to a file.

I think that at one point, we changed J4 files so that if you made them read
only, then they would not use binary/group locks. chmod a-r should tell you.
This could well have changed of course and probably is not implemented for
JR files.

Jim

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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 <[email protected]> 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: [email protected] [mailto:[email protected]] On
> > > Behalf Of Pawel (privately)
> > > Sent: Monday, August 15, 2011 12:56 PM
> > > To: [email protected]
> > > 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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 [email protected] To unsubscribe, send
> email to [email protected]
> For more options, visit this group at
> http://groups.google.com/group/jBASE?hl=en

-- 
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

Reply via email to