Re: [U2] OPENSEQ and Abnormal termination of UV

[Brian Leach]

Wol

>In BASIC, *EVERYTHING* is a string (apart from file variables). 
>Therefore any comparison should be valid.

To be more precise, no.

UniVerse Basic is a run-time typed language (like PHP) not a string
language. So it gets the performance and storage benefits of real types, and
coerces between types under the cover. If you say For I = 1 To 10, and
examine I in the debugger, you will see that it is an integer, not a string.
If you later say I="FRED" it will be coerced into a string, as will I :=
"FRED" or I<2> = "FRED".

In addition to file variables, there are plenty other structures that are
not coercible into strings: select list handles (from EXECUTE statement,
SELECT. > SOMELIST), XML DOM handles and BCI context handles to name but a
few.

It may seem pedantic, but these distinctions are important when selling the
benefits of language like UniVerse Basic. The word 'untyped' offends some
sectors of the programming community. 'run-time typed' is generally more
acceptable. (and it's funny how many developers sneer at the first mention
of these, until you follow up with the PHP analogy.. and suddenly they see
the light).

Brian




___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Bill Haskett]

"...That's what I absolutely HATE about "artificial stupidity". It 
thinks it knows better than me, and gives me what it thinks I should 
have, not what I asked for."


Then again, I can't imagine it thinks it should CRASH!  :-o

Bill


Anthony W. Youngman said the following on 5/21/2010 5:15 PM:
In message <321088.49154...@web36901.mail.mud.yahoo.com>, Jacques G. 
 writes

[snipped]


[snipped]

At the end of the day, an IF test for equality should return FALSE on 
a type mismatch, not CRASH. Because FALSE is the *correct* answer. 
That's what I absolutely HATE about "artificial stupidity". It thinks 
it knows better than me, and gives me what it thinks I should have, 
not what I asked for.


Cheers,
Wol

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[fft2001]

 I know what you're saying, but just to make sure we're precise I'll add a 
footnote.
The run-time machine doesn't have to find additional memory *each* time you add 
to a dynamic array (as you said perhaps just imprecisely).  Rather, your 
workspace arrays have certain fixed sizes and it's only when you go over this 
size that it will allocate you a new larger area and move the array there.  So 
for example, you get slots that are 50 bytes, 250 bytes, and so on, probably 
implementation dependent.  The run-time machine will allocate you a smaller 
area at first, until it knows you need a bigger one.

Alternatively, garbage collection will return to the available pool, the no 
longer used space for arrays that have shrunk.

I never did any testing to see if the garbage collector actually works *while* 
your program is running or only after the signal that the program is now 
finished.

 

 I do agree however with the observation that reading a large amount of data 
into a dynamic array is *most likely* causing the run-time machine to allocate 
you the entire size of that data in your own *workspace*.  Danger Will 
Robinson!  Warning! Warning!

When it runs out of memory/disk will it wait forever? Or will it halt the 
system?
"Try again later, answer fuzzy".

Will Johnson




 

 

-Original Message-
From: John Hester 
To: U2 Users List 
Sent: Tue, May 18, 2010 12:31 pm
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 
, John 
Hester  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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Anthony W. Youngman]

In message <321088.49154...@web36901.mail.mud.yahoo.com>, Jacques G. 
 writes
If your file is opened, then comparing it to an empty string is what 
will cause an invalid data type error.




WHY!!!



If the datatypes don't match, then the result of the comparison is
FALSE, not INVALID.



It is logically correct to do such a comparison. The result I am looking
for is the logically correct response. It SHOULD NOT crash the program!



And it worked fine on INFORMATION, why not UV?


It is a bad idea to allow it, it encourages bad programming practices 
and it can hide a bug in your program for example if you do:


READ CAR FROM CARS ELSE CAR = ''
IF CARS #  ''  THEN

Here what was intended was to compare CAR to ''  not CARS but having 
the S there is a typo.
If we don't allow datatypes of different types being compared this bug 
has a greater chance of getting caught during development because the 
program will fail on comparing the file to a null string.


If you use FILEINFO it shows that you know that the variable you are 
testing is a file.


The big problem with your attitude is that you are assuming a typed 
language - and even then it's invalid.


In BASIC, *EVERYTHING* is a string (apart from file variables). 
Therefore any comparison should be valid.


And, using your own words against you - "it shows that you know that the 
variable you are testing is a file." What if I DON'T know (which is why 
I was doing the test!).


At the end of the day, an IF test for equality should return FALSE on a 
type mismatch, not CRASH. Because FALSE is the *correct* answer. That's 
what I absolutely HATE about "artificial stupidity". It thinks it knows 
better than me, and gives me what it thinks I should have, not what I 
asked for.


Cheers,
Wol
--
Anthony W. Youngman 
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source Pick
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Jacques G.]

>If your file is opened, then comparing it to an empty string is what will 
>cause an invalid data type error.


>WHY!!!

>If the datatypes don't match, then the result of the comparison is 
>FALSE, not INVALID.

>It is logically correct to do such a comparison. The result I am looking 
>for is the logically correct response. It SHOULD NOT crash the program!

>And it worked fine on INFORMATION, why not UV?

It is a bad idea to allow it, it encourages bad programming practices and it 
can hide a bug in your program for example if you do:

READ CAR FROM CARS ELSE CAR = ''
IF CARS #  ''  THEN

Here what was intended was to compare CAR to ''  not CARS but having the S 
there is a typo.
If we don't allow datatypes of different types being compared this bug has a 
greater chance of getting caught during development because the program will 
fail on comparing the file to a null string.

If you use FILEINFO it shows that you know that the variable you are testing is 
a file.

I've seen a similar case where a subroutine was expecting:

SUBROUTINE  ABC (MAT A, MAT B, MAT C)

A programmer only needed the contents of the matrix B and C to call it and did:

CALL ABC("",MAT B, MAT C)

Only thing Matrix ABC puts something in MAT A and since the programmer passed 
an empty string what happens is that the content of Matrix B is over-written 
causing data corruption.

It would probably have been a good idea to detect that since a Matrix was 
expected, it shouldn't be legal to pass a dynamic array to the subroutine.  

Most modern OOP programming languages don't allow for types of different kinds 
to be compared to one another without some way of casting them.  


  
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Anthony W. Youngman]

In message <536051.22442...@web36905.mail.mud.yahoo.com>, Jacques G. 
 writes

Oh - that reminds me of something else I'd call a bug. It might well have been 
fixed by now (I met it in 9.6) but you couldn't safely use a file variable
in an IF statement. Can't remember the details, but it was something like




FVAR = ""
some conditional code
OPEN FILE TO FVAR
more code
IF FVAR EQ "" THEN
oh the file isn't open, so do whatever


If your file is opened, then comparing it to an empty string is what will cause 
an invalid data type error.


WHY!!!

If the datatypes don't match, then the result of the comparison is 
FALSE, not INVALID.


It is logically correct to do such a comparison. The result I am looking 
for is the logically correct response. It SHOULD NOT crash the program!


And it worked fine on INFORMATION, why not UV?

Cheers,
Wol
--
Anthony W. Youngman 
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source Pick
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Jacques G.]

Using dimmed matrixes is still a lot faster.  

If you have a dynamic array of 10,000 items and you wantA<9995> when you 
extract it, it will parse the whole until it passes 9994 @AM then it will 
extract whatever is between the 9994 and 9995.
Having it in a dynamic array is like having a pointer to each @AM position.

This is why the REMOVE command was added for when a dynamic array is processed 
within a for loop.  The REMOVE command keeps track of the position of the last 
AM, VM, SVM used.

One exemple:   
DIM B(10)
A = CONVERT("]",@AM,"AA]BB]]")
MATPARSE B FROM A USING @AM

B now has a pointer to each of the 4 elements of 4:
B(1) ->  "AA"
B(2) -> "B"
B(3) -> ""
B(4) -> ""

When you want the third row, you don't have to pass through the contents of 
B(1) and B(2) you have a pointer to the start of the string that contains 
"".


I've used dimmed matrixes to speed sorts and binary search algorithms.

One other advantage of a dimmed matrix is that you can use it to pass several 
files as arguments to a subroutine.  With a dynamic array it can only be a file 
or a string.  You don't change a subroutine's signature if you pass  

call MYSUB(MAT FILES,MAT ARGV_IN, MAT ARGV_OUT)

This way you can add to the number of files and arguments of a subroutine 
without changing the number of arguments.  With dynamic arrays you would have 
to add more arguments to add more files. Ei from:

CALL MYSUB(FILE1, ARGV_IN, ARGV_OUT)

to 

CALL MYSUB(FILE1, FILE2, ARGV_IN, ARGV_OUT)

This means each program calling MYSUB has to be modified.



- Original Message 
From: John Hester 
To: U2 Users List 
Sent: Tue, May 18, 2010 3:31:25 PM
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


  
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Jacques G.]

>Oh - that reminds me of something else I'd call a bug. It might well have been 
>fixed by now (I met it in 9.6) but you couldn't safely use a file variable in 
>an IF statement. Can't remember the details, but it was something like


>FVAR = ""
>some conditional code
>OPEN FILE TO FVAR
>more code
>IF FVAR EQ "" THEN
>oh the file isn't open, so do whatever

If your file is opened, then comparing it to an empty string is what will cause 
an invalid data type error.   You want to do instead:

IF FILEINFO(FVAR,0) = 0 THEN

Or:

OPEN FILE TO FVAR THEN FLAG.OPEN = 1 ELSE FLAG.OPEN = 0
IF FLAG.OPEN THEN

One error I've seen:

READ CUSTOMER FROM CUSTOMER THEN...

The record item that is being read is the same name as the opened file 
variable... ouch !


  
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Rex Gozar]

> Anthony W. Youngman 
> 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
> thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
> lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
> Visit the MaVerick web-site -  Open Source
> Pick

Anthony,

Did you know that clicking on your "maverick" link in your signature
brings up the "janitor's warehouse" website?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Anthony W. Youngman]

In message 
, John 
Hester  writes

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.


"Illegal assignment".

You can't store a file descriptor in a dynamic array, because it's not a 
character string (it MIGHT be implemented as such, but it doesn't make 
sense to treat it as such, so it's a logical stupidity. I don't know of 
any MV implementation that permits this).


Cheers,
Wol


-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
, John
Hester  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


--
Anthony W. Youngman 
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Brian Leach]

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

Doubtful..

I'm guessing under the hood the array will resolve to a series of pointers
somewhere down the track, but those pointers will need to be cast to
different types depending on what is being stored in the array - a variable,
a file pointer, a sequential file pointer etc. So something in that cast
will be wrong - it might for example be that whatever structure controls a
sequential file originally contained a 32 bit address and now doesn't but
the cast is still expecting that, or that it gets copied with an alignment
change or something similar. 

In other words, typical C bug from a pretty unlikely occurrence.

Brian

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[John Hester]

Only the UV or UD developers could say for sure, but I'd venture to
guess that multi-gigabyte sequential files weren't envisioned when the
dimensioned array code was written.  Maybe there's never been a request
to revisit it.  I quit using dimensioned arrays probably around the late
90's when faster hardware seemed to negate any performance advantage.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen
Sent: Tuesday, May 18, 2010 12:59 PM
To: 'U2 Users List'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

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
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Symeon Breen]

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 
, John 
Hester  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

Re: [U2] OPENSEQ and Abnormal termination of UV

[John Hester]

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 
, John 
Hester  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

Re: [U2] OPENSEQ and Abnormal termination of UV

[John Hester]

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 
, John 
Hester  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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Anthony W. Youngman]

In message 
, John 
Hester  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.

Oh - that reminds me of something else I'd call a bug. It might well 
have been fixed by now (I met it in 9.6) but you couldn't safely use a 
file variable in an IF statement. Can't remember the details, but it was 
something like


FVAR = ""
some conditional code
OPEN FILE TO FVAR
more code
IF FVAR EQ "" THEN
oh the file isn't open, so do whatever

That worked fine on PI, but crashed UV. Perfectly reasonable thing to 
do, but UV Basic wouldn't have it. Oh yes - I think it was file 
variables declared in common. Common forces all variables to default to 
the empty string so all my PI code tested for the empty string. Only to 
blow up when we compiled it on UV.


Cheers,
Wol
--
Anthony W. Youngman 
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source Pick
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[aelwood]

Normally when I run into a statement that doesn't like mv or dimmed arrays I 
just assign before or after

Like:
SEARCH.FOR = ABC<1,J>
LOCATE SEARCH.FOR IN DEF SETTING bla bla bla

or in this case

OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO SEQ.TEST ELSE ABORT
FVARS(1) = SEQ.TEST

I haven't tested this to see if it works - I have my own dragons to slay right 
now  :-)

 Perry Taylor  wrote: 

=
I'd call this one a bug.  I just tried the following on 10.2.7 on
RHEL5...

  OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO SEQ.TEST ELSE ABORT

  STATUS FS FROM SEQ.TEST ELSE ABORT

  CLOSESEQ SEQ.TEST

  CRT 'FILE SIZE = ': FS<6>

I get...

FILE SIZE = 10146506752

But if I run...

  DIM FVARS(10)

  OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO FVARS(1) ELSE ABORT

  STATUS FS FROM FVARS(1) ELSE ABORT

  CLOSESEQ FVARS(1)

  CRT 'FILE SIZE = ': FS<6>

I get...

Abnormal termination of UniVerse.
Fault type is 11.  Layer type is BASIC run machine.
Fault occurred in BASIC program PTEST at address 5a.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Marc A
Hilbert
Sent: Monday, May 17, 2010 3:41 PM
To: 'U2 Users List'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

What happens wif you open to regular variable then pass it over to the
array:
OPENSEQ  TO FVAR
FILEVARS(1) = FVAR
?
Regards,
Marc


-Mensaje original-
De: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] En nombre de Rajesh Menon
Enviado el: lunes, 17 de mayo de 2010 16:12
Para: U2 Users List
Asunto: Re: [U2] OPENSEQ and Abnormal termination of UV

Yes file system is setup to support +2Gb files. As I mentioned I can
open
the file using a scalar file variable. Problem happening only with the
combination of +2Gb and using array variable.

Thanks,
Rajesh

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble
Sent: Monday, May 17, 2010 12:00 PM
To: 'u2-users@listserver.u2ug.org'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

You may want to check with your Systems Administrator to be sure your
file
system is setup to support files larger than 2gig

- Original Message -
From: u2-users-boun...@listserver.u2ug.org

To: u2-users@listserver.u2ug.org 
Sent: Mon May 17 14:55:30 2010
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11.
Fault
occurred at address 1c (which is the OPENSEQ command.). If the file size
is
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work
irrespective
of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
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

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

CONFIDENTIALITY NOTICE: This e-mail message, including any 
attachments, is for the sole use of the intended recipient(s) 
and may contain confidential and privileged information.  Any
unauthorized review, use, disclosure or distribution is 
prohibited. ZirMed, Inc. has strict policies regarding the 
content of e-mail communications, specifically Protected Health 
Information, any communications containing such material will 
be returned to the originating party with such advisement 
noted. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the 
original message.
___
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

Re: [U2] OPENSEQ and Abnormal termination of UV

[John Hester]

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.

One workaround might be to use EXECUTE to shell out to an OS-level
command or script that parses the file out into multiple smaller temp
files that can then be accessed by UV.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug
Sent: Monday, May 17, 2010 12:33 PM
To: 'U2 Users List'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

Let me see, can it be because you are trying to cram over 4 GB of data
into
a single cell. Unlike the OPEN statement that just puts the file
variable
into a variable, the OPENSEQ opens the whole file to the variable.

Jerry Banker

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon
Sent: Monday, May 17, 2010 1:56 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11.
Fault
occurred at address 1c (which is the OPENSEQ command.). If the file size
is
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work
irrespective
of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Perry Taylor]

I'd call this one a bug.  I just tried the following on 10.2.7 on
RHEL5...

  OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO SEQ.TEST ELSE ABORT

  STATUS FS FROM SEQ.TEST ELSE ABORT

  CLOSESEQ SEQ.TEST

  CRT 'FILE SIZE = ': FS<6>

I get...

FILE SIZE = 10146506752

But if I run...

  DIM FVARS(10)

  OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO FVARS(1) ELSE ABORT

  STATUS FS FROM FVARS(1) ELSE ABORT

  CLOSESEQ FVARS(1)

  CRT 'FILE SIZE = ': FS<6>

I get...

Abnormal termination of UniVerse.
Fault type is 11.  Layer type is BASIC run machine.
Fault occurred in BASIC program PTEST at address 5a.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Marc A
Hilbert
Sent: Monday, May 17, 2010 3:41 PM
To: 'U2 Users List'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

What happens wif you open to regular variable then pass it over to the
array:
OPENSEQ  TO FVAR
FILEVARS(1) = FVAR
?
Regards,
Marc


-Mensaje original-
De: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] En nombre de Rajesh Menon
Enviado el: lunes, 17 de mayo de 2010 16:12
Para: U2 Users List
Asunto: Re: [U2] OPENSEQ and Abnormal termination of UV

Yes file system is setup to support +2Gb files. As I mentioned I can
open
the file using a scalar file variable. Problem happening only with the
combination of +2Gb and using array variable.

Thanks,
Rajesh

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble
Sent: Monday, May 17, 2010 12:00 PM
To: 'u2-users@listserver.u2ug.org'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

You may want to check with your Systems Administrator to be sure your
file
system is setup to support files larger than 2gig

- Original Message -
From: u2-users-boun...@listserver.u2ug.org

To: u2-users@listserver.u2ug.org 
Sent: Mon May 17 14:55:30 2010
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11.
Fault
occurred at address 1c (which is the OPENSEQ command.). If the file size
is
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work
irrespective
of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
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

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

CONFIDENTIALITY NOTICE: This e-mail message, including any 
attachments, is for the sole use of the intended recipient(s) 
and may contain confidential and privileged information.  Any
unauthorized review, use, disclosure or distribution is 
prohibited. ZirMed, Inc. has strict policies regarding the 
content of e-mail communications, specifically Protected Health 
Information, any communications containing such material will 
be returned to the originating party with such advisement 
noted. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the 
original message.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[Marc A Hilbert]

What happens wif you open to regular variable then pass it over to the
array:
OPENSEQ  TO FVAR
FILEVARS(1) = FVAR
?
Regards,
Marc


-Mensaje original-
De: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] En nombre de Rajesh Menon
Enviado el: lunes, 17 de mayo de 2010 16:12
Para: U2 Users List
Asunto: Re: [U2] OPENSEQ and Abnormal termination of UV

Yes file system is setup to support +2Gb files. As I mentioned I can open
the file using a scalar file variable. Problem happening only with the
combination of +2Gb and using array variable.

Thanks,
Rajesh

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble
Sent: Monday, May 17, 2010 12:00 PM
To: 'u2-users@listserver.u2ug.org'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

You may want to check with your Systems Administrator to be sure your file
system is setup to support files larger than 2gig

- Original Message -
From: u2-users-boun...@listserver.u2ug.org

To: u2-users@listserver.u2ug.org 
Sent: Mon May 17 14:55:30 2010
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11. Fault
occurred at address 1c (which is the OPENSEQ command.). If the file size is
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work irrespective
of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
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

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] OPENSEQ and Abnormal termination of UV

[jpb-u2ug]

Let me see, can it be because you are trying to cram over 4 GB of data into
a single cell. Unlike the OPEN statement that just puts the file variable
into a variable, the OPENSEQ opens the whole file to the variable.

Jerry Banker

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon
Sent: Monday, May 17, 2010 1:56 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11. Fault
occurred at address 1c (which is the OPENSEQ command.). If the file size is
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work irrespective
of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Buffington, Wyatt]

I far as I know. The OPENSEQ statement requires both a file name and a
record name.
(i.e.: OPENSEQ DATA.DIRECTORY, FLAT.FILE.NAME TO F.TEMP ELSE ...)

HTH


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon
Sent: Monday, May 17, 2010 2:09 PM
To: U2 Users List
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

I already tried that. Same Error and the fault occurring at FILEVAR(1) =
FV.TEMP line.

Thanks,
Rajesh
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Monday, May 17, 2010 11:59 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

Just for giggles... what happens if you...

OPENSEQ '/tmp/file.txt' TO FV.TEMP ELSE ...
FILEVARS(1) = FV.TEMP 

??

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon
Sent: Monday, May 17, 2010 2:56 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11.
Fault occurred at address 1c (which is the OPENSEQ command.). If the
file size is less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work
irrespective of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information.  Any unauthorized review, use,
disclosure or distribution is prohibited. ZirMed, Inc. has strict
policies regarding the content of e-mail communications, specifically
Protected Health Information, any communications containing such
material will be returned to the originating party with such advisement
noted. If you are not the intended recipient, please contact the sender
by reply e-mail and destroy all copies of the original message.
___
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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Rajesh Menon]

Yes file system is setup to support +2Gb files. As I mentioned I can open the 
file using a scalar file variable. Problem happening only with the combination 
of +2Gb and using array variable.

Thanks,
Rajesh

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble
Sent: Monday, May 17, 2010 12:00 PM
To: 'u2-users@listserver.u2ug.org'
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

You may want to check with your Systems Administrator to be sure your file 
system is setup to support files larger than 2gig

- Original Message -
From: u2-users-boun...@listserver.u2ug.org 

To: u2-users@listserver.u2ug.org 
Sent: Mon May 17 14:55:30 2010
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file 
variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11. Fault 
occurred at address 1c (which is the OPENSEQ command.). If the file size is 
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work irrespective of 
the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Rajesh Menon]

I already tried that. Same Error and the fault occurring at FILEVAR(1) = 
FV.TEMP line.

Thanks,
Rajesh
-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Monday, May 17, 2010 11:59 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV

Just for giggles... what happens if you...

OPENSEQ '/tmp/file.txt' TO FV.TEMP ELSE ...
FILEVARS(1) = FV.TEMP 

??

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon
Sent: Monday, May 17, 2010 2:56 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11.
Fault occurred at address 1c (which is the OPENSEQ command.). If the
file size is less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work
irrespective of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

CONFIDENTIALITY NOTICE: This e-mail message, including any 
attachments, is for the sole use of the intended recipient(s) 
and may contain confidential and privileged information.  Any
unauthorized review, use, disclosure or distribution is 
prohibited. ZirMed, Inc. has strict policies regarding the 
content of e-mail communications, specifically Protected Health 
Information, any communications containing such material will 
be returned to the originating party with such advisement 
noted. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the 
original message.
___
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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Dan Goble]

You may want to check with your Systems Administrator to be sure your file 
system is setup to support files larger than 2gig

- Original Message -
From: u2-users-boun...@listserver.u2ug.org 

To: u2-users@listserver.u2ug.org 
Sent: Mon May 17 14:55:30 2010
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file 
variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11. Fault 
occurred at address 1c (which is the OPENSEQ command.). If the file size is 
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work irrespective of 
the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
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

Re: [U2] OPENSEQ and Abnormal termination of UV

[Perry Taylor]

Just for giggles... what happens if you...

OPENSEQ '/tmp/file.txt' TO FV.TEMP ELSE ...
FILEVARS(1) = FV.TEMP 

??

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon
Sent: Monday, May 17, 2010 2:56 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] OPENSEQ and Abnormal termination of UV

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the
file variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11.
Fault occurred at address 1c (which is the OPENSEQ command.). If the
file size is less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work
irrespective of the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

CONFIDENTIALITY NOTICE: This e-mail message, including any 
attachments, is for the sole use of the intended recipient(s) 
and may contain confidential and privileged information.  Any
unauthorized review, use, disclosure or distribution is 
prohibited. ZirMed, Inc. has strict policies regarding the 
content of e-mail communications, specifically Protected Health 
Information, any communications containing such material will 
be returned to the originating party with such advisement 
noted. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the 
original message.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

[U2] OPENSEQ and Abnormal termination of UV

[Rajesh Menon]

Does anyone knows what is happening here:
I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file 
variable into a array as follows:
COMMON /MYPROG/ FILEVARS(10)
OPENSEQ "/tmp/file.txt" to FILEVARS(1) ELSE ...
This operation results abnormal termination with fault type error 11. Fault 
occurred at address 1c (which is the OPENSEQ command.). If the file size is 
less than 2147483647 bytes (2Gb), it works.

Opening the same file using a scalar file variable always work irrespective of 
the file size.
OPENSEQ "/tmp/file.txt" TO FV.FILE ELSE ...

Any reason why the first method failing for +2Gb files? Any workarounds?

Universe: 10.2.7
AIX:  5.3

Thanks
Rajesh Menon

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users