Surely it is just a pointer to the file and the position in that file - i open many multi gigabyte files using openseq and i would not expect the udt process to allocate tens of Gig at that time for the readseq operations ... It should be a tiny piece of memory to act as a pointer !! ??
-----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: 18 May 2010 20:31 To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Reading my own response just made me realize what's going on. I think Jerry's response was right. I remember many years ago (I won't say how many) when we were on much slower hardware, explaining to a coworker that it was better to use dimensioned arrays when possible because they were faster to populate than dynamic arrays. The reason they're faster is because the necessary space for them is already reserved in memory. A dynamic array has to go out and find add'l memory each time you add to it. Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. If that's the case then making FILEVARS a dynamic array *should* work. -John -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: Tuesday, May 18, 2010 11:42 AM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Yes, I see your point. I wonder if the integer gets treated like a string in the first instance. I wonder what the result with FILEVARS<1> would be. -John -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthony W. Youngman Sent: Tuesday, May 18, 2010 7:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OPENSEQ and Abnormal termination of UV In message <e6179e13392ec14aabcd5272c3aedd61124ec...@exchangesvr.momtex.com>, John Hester <jhes...@momtex.com> writes >I think it's something along those lines, but I don't think it's trying >to stick the entire contents of the file into a variable. What I think >OPENSEQ is doing is keeping track of the position where the EOF mark is >so it will know when the end of the file is reached. For a file greater >than 2GB in size, this position is an integer that takes more than 32 >bits to store. UV, being a 32-bit application, is not going to be able >to handle it. The maximum positive integer value a 32-bit application >can reference is 2147483647. > The problem is, FV.FILE and FILEVARS(1) are *allegedly* *functionally* *identical*. An element of a dimensioned array, is supposed to be a normal variable in every way shape or form. The problem is that, in this instance, it clearly isn't because the variable works while the element (allegedly identical) causes a crash. I'd agree with Perry. It's a bug. _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
