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 -

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