Hi, This is too late, but should be part of preventive maintenance. For example we check everyday the size, when exceeds above 1,5 gb. We are doing archiving or make the file distributed. Oracle as a database is also an option.
Regards On Apr 23, 8:13 am, udayangi <[email protected]> wrote: > Thanks Jim for your reply. > > yes the file is being archived and on this particular instance, they > have not done it on time. I would like to whether there is anything > to do with ulimit setting here. > > udayangi > > On Apr 22, 10:41 pm, Jim Idle <[email protected]> wrote: > > > > > udayangi wrote: > > > Hi > > > > Recently I found out one of the large files in T24 R6.003 reached 2GB > > > and even grew beyond 2GB. However the file got corrupted and it was > > > noticed later. Usually I have seen Error 27 if I try to write to the > > > file and if it reaches 2GB. Pls help me to understand why there was > > > not such error reported and why the file grew beyond 2GB when T24 has > > > a limitation of 2GB. > > > > These are the info. of my environment > > > > OS - Sun Solaris 10 > > > jbase - 4.1.5.17 > > > T 24 - R6.003 > > > > ulimit output. > > > > jsh test1 ~ -->ulimit -a > > > time(seconds) unlimited > > > file(blocks) unlimited > > > data(kbytes) unlimited > > > stack(kbytes) unlimited > > > coredump(blocks) unlimited > > > nofiles(descriptors) 8192 > > > vmemory(kbytes) unlimited > > > jsh test1 ~ --> > > > > Is it due to the data(kbytes) in ulimit is set to unlimited > > > Hi, > > > The limitation is that the offsets and so on in the file format are > > limited to signed 32 bit integers. However, internally, these numbers > > can appear to get bigger than that, but will end up going negative, or > > wrapping and so on and the C runtime assumes you know what you are > > doing. I know programmers who use these quirks as 'optimizations' in > > fact - they shouldn't, but they do. > > > So, when a file gets to a point where the 2GB limit is reached, you can > > end up writing a record that pushes the file over 2GB, but not > > discovering this until you try to read it, at which point the pointers > > will be wrong and be rejected. In turn, this is because most file > > systems these days do not limit a file to a 2GB limit, so the write the > > extends the file beyond 2GB will not be rejected (though a write to an > > incorrect offset that tries to be >2GB will throw an error). > > > Other jBASE file types are not limited to the 2GB, 32 bit interface to > > the file system and you might wish to use these. However, in general > > your system will probably be more efficient if you archive data or > > partition it and so on, so that you do not get files of 2GB (though > > there are of course times when this is desirable). > > > Jim- Hide quoted text - > > > - Show quoted text -- 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 -~----------~----~----~----~------~----~------~--~---
