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
