RE: [U2] unibasic select woes
Greg, Actually the following in saver: SELECT HRPER WITH EVAL OCONV(HRP.LAST.NAME,'MCU') LIKE 'SC'... (note the extra ' around the text) there are a few alphanumeric characters that are interpreted by SELECT and it will show you weird results when you are not expecting that. Regards, Andre -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Schraiber Sent: maandag 30 april 2007 11:12 To: u2-users@listserver.u2ug.org; u2-users@listserver.u2ug.org Subject: RE: [U2] unibasic select woes Dave, Wyatt Karen, Thank you so much for the tips! Works like a charm! Thanks again, Greg At 12:45 PM 5/30/2007, Dave Davis wrote: In ECLTYPE u SELECT HRPER WITH EVAL OCONV(HRP.LAST.NAME,'MCU') LIKE SC... If you are currently in ECLTYPE p, you can put the word SELECT in lowercase to evaluate using the u parser. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Schraiber Sent: Wednesday, May 30, 2007 1:28 PM To: u2-users@listserver.u2ug.org Subject: [U2] unibasic select woes How does one select alpha-numeric data from a unidata datafile using SELECT when the case of the text is not known? I have tried things like: SELECT HRPER WITH UPCASE(HRP.LAST.NAME) LIKE 'SC...' but all I get is a syntax error. Can someone tell me which function(s) can be used to facilitate this type of search? Any help is greatly appreciated! Thank you, Greg --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Dynamic files, big transactions
All, I have done some more digging and I'm now stuck at writing about 6k new records within one transaction. I don't know what I might be missing but depending on different variations I get a max of 5k or 6k and then a READU threshold reached error will break the transaction. Any more insights will be greatly appreciated. I have pasted info of my last test below. Regards, Andre Meij Innovate-IT DELETE.FILE TEST06 DELETEd TEST06, Type 30. DELETEd file D_TEST06, Type 3, Modulo 1. DELETEd file definition record TEST06 in the VOC file. CREATE.FILE TEST06 30 MINIMUM.MODULUS 1024 SEQ.NUM Creating file TEST06 as Type 30. Creating file D_TEST06 as Type 3, Modulo 1, Separation 2. Added @ID, the default record for RetrieVe, to D_TEST06. ANALYZE.FILE TEST06 File name .. TEST06 Pathname ... TEST06 File type .. DYNAMIC Hashing Algorithm .. SEQUENTIAL No. of groups (modulus) 1024 current ( minimum 1024 ) Large record size .. 1628 bytes Group size . 2048 bytes Load factors ... 80% (split), 50% (merge) and 0% (actual) Total size . 2101248 bytes RUN BP test 15000 5 Starting writing 5 records READU threshold reached, lock on 11521224 denied! Completed writing 6223 records Error: WARNING, 'TEST06' record '11521224' locked, try again later. GROUP.STAT.DETAIL TEST06 Type description= Hashed, keys end in numbers. Bytes Record.id File= TEST06 Modulo= 1024 Sep= 4 Type= 30 32 11518037 32 11520098 32 11519718 32 11516722 32 11517008 -- 160 Bytes 5 Records in Group 1 32 11518036 32 11517009 32 11520099 32 11519719 32 11516723 -- 160 Bytes 5 Records in Group 2 32 11518038 32 11517011 32 11520096 32 11519716 32 11516720 LIST.READU (started before the end of the transaction after the READU error. Active Record Locks: Device Inode Netnode Userno LmodePid Login Id Item-ID. 22282244 12580680 115 RU 21074 ameij11515011 22282244 12580680 115 RU 21074 ameij11515033 22282244 12580680 115 RU 21074 ameij11515068 22282244 12580680 115 RU 21074 ameij11515102 22282244 12580680 115 RU 21074 ameij11515135 22282244 12580680 115 RU 21074 ameij11515146 22282244 12580680 115 RU 21074 ameij11515161 22282244 12580680 115 RU 21074 ameij11515179 22282244 12580680 115 RU 21074 ameij11515218 22282244 12580680 115 RU 21074 ameij11515235 22282244 12580680 115 RU 21074 ameij11515284 22282244 12580680 115 RU 21074 ameij11515298 22282244 12580680 115 RU 21074 ameij11515315 22282244 12580680 115 RU 21074 ameij11515334 22282244 12580680 115 RU 21074 ameij11515351 22282244 12580680 115 RU 21074 ameij11515364 22282244 12580680 115 RU 21074 ameij11515420 22282244 12580680 115 RU 21074 ameij11515453 22282244 12580680 115 RU 21074 ameij11515468 22282244 12580680 115 RU 21074 ameij11515477 22282244 12580680 115 RU 21074 ameij11515510 22282244 12580680 115 RU 21074 ameij11515548 22282244 12580680 115 RU 21074 ameij11515565 22282244 12580680 115 RU 21074 ameij11515579 22282244 12580680 115 RU 21074 ameij11515608 22282244 12580680 115 RU 21074 ameij11515627 22282244 12580680 115 RU 21074 ameij11515649 22282244 12580680 115 RU 21074 ameij11515685 22282244 12580680 115 RU 21074 ameij11515718 22282244 12580680 115 RU 21074 ameij11515751 22282244 12580680 115 RU 21074 ameij11515769 22282244 12580680 115 RU 21074 ameij11515791 22282244 12580680 115 RU 21074 ameij11515798 22282244 12580680 115 RU 21074 ameij11515824 22282244 12580680 115 RU 21074 ameij11515860 22282244 12580680 115 RU 21074 ameij11515893 22282244 12580680 115 RU 21074 ameij11515928 22282244 12580680 115 RU 21074 ameij11515945 22282244 12580680 115 RU 21074 ameij11515965 22282244 12580680 115 RU
RE: [U2] Dynamic files, big transactions
Rick, Charles, et others, Thank you for the quick answers. I have quickly tried your solutions and both the initial create with bigger hash and the change+resize on an existing file seem to work, I can now easily lock 20k records in one transaction. I have yet to find out why we hit this issue on live servers in our application (so why the hash on the affected files is apparently so small. I will take a look at that Monday. For now I am quite happy because I have a solution for the immediate problem. Also I have been trying to SELECT 40k records after the write of 20k new ones and that worked also, I am very confused now because I have been brought up with the idea that there is no thing more disastrous then a SELECT in a Universe transaction (locking table problems all around I am told.) Is that something you have heard of? Or is it just another fable? Thanks again for the help, it is very much appreciated. Regards, Andre Meij Innovate-IT -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Saturday, March 10, 2007 7:04 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Dynamic files, big transactions Andre, I'm with Rick. He suggested new partfile. But maybe some kind of queue or workfile, that routinely gets flushed, merging to modulo 1. And maybe zero length record or very small, so that 250 ids all land in the same group? Is group size 4KB? What does that have to do with the lock table in memory, you (or some lurker) may ask? When a record is locked, UV uses the inode group# to determine where to plant the lock in the lock table. So that means that all these records will be assigned to the same lock group, since inode group# (i.e., 1) will be the same for all. If you gave it a larger minimum.modulus, or converted that queue/work file to static, then, when you lock many or all records at once, that would spread the load across several lock groups, since the inodegroup# combo would vary from record to record. cds P.S. I *think* splits and merges are suspended on groups that have records currently in the lock table. (Since group# determines where something is in the lock table, you couldn't have that being changed out from under you.) So as long as a record remains locked, your dynamic file will be not quite so dynamic. You might be hitting that, too. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Dynamic files, big transactions
Hi, We have a highly technical problem with universe related to the locking tables and their configuration: We have a big application running on Universe 10.1 (Solaris). This application is build on Distributed Dynamic files. Some of the keys are auto numbers; others are supplied by external systems. With our current settings we can have a maximum of 250 locks in one group; this means most certainly for auto numbers we can only lock records 1000 to 1249 without getting an abort and a rollback because a new lock cannot be acquired. This 250th lock cannot be acquired because all these locks fall within the same lock group which is limited to 250 locks. I know of 2 uvconfig parameters that define this locking behavior however the maximum settings of these settings are limited by the maximum size of the shared memory segment. # GLTABSZ - sets the number of group lock entries GLTABSZ 250 # RLTABSZ - sets the number of read lock entries RLTABSZ 250 Our testing indicated that these numbers cannot be raised any higher (due to the shared memory limit). This all means that I cannot lock more than 250 records in one transaction; this is unfortunately not always enough, we occasionally have to implement some extensive tricks to circumvent this. I very much would like to see this resolved on a Universe level so that the programmers can stop worrying about this. Anyone who has experience or knows of someone with experience, please help :-). Maybe you have knowledge of this problem yourself or know of somebody within IBM who could help us resolve this. Regards, Andre Meij Innovate-IT --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UV 10.2 has been (announced) released
Hi, Has anybody been able to find the complete releasenotes (+ new docs) for this new version? Regards, Andre Meij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hennessey, Mark F. Sent: Friday, September 29, 2006 2:56 PM To: u2-users@listserver.u2ug.org Subject: [U2] UV 10.2 has been announced Did everyone get their marketing-gram from Janet Oswald? --- We are pleased to announce that IBM UniVerse. 10.2 will be generally available on September 29, 2006. This release protects personal data, supports U2 Web Services, strengthens and streamlines high availability, and more! Read the full product announcement at http://www.ibm.com/software/data/u2/universe/universe10-2.html If you have any questions on the information, please send them to [EMAIL PROTECTED] --- It appears that the product availability page has not been updated yet Mark Hennessey --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Internal data error
Hi, A (unfortunate) common problem when a server is reset when files are in use. The internal file structure becomes corrupted. Our procedure for repair is the following: One the unix commandline: cp -r directoryname directoryname.backup fixtool -file directoryname (this will show an overview of errors) Fixtool -file directoryname -fix (this will attempt to fix the file) BUT fixtool is improved in the later versions (10.0 and above) so you might not want to use it! After the copy you can run on the Universe commandline: uvfixfile filename this works on all versions but not on 64bit files. Hope this helps, hoping for you that you do not encounter this often. If you need more help contact me. Regards, Andre Meij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teri Henry Sent: Friday, October 06, 2006 7:02 PM To: u2-users@listserver.u2ug.org Cc: IT Support Subject: [U2] Internal data error Universe 9.5 Received the following error and would be grateful to know what it means and suggestions as to type of maintenance/correction needed. Internal data error. File 'E:\usr1\MASTER/ICE': Computed blink of 0x1EC0C000 does not match expected blink of 0x520E8000! Detected within group starting at address 0x1EC0C000! Many thanks! Teri Henry [demime 1.01d removed an attachment of type image/gif which had a name of Blank Bkgrd.gif] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
