I've never used OPENSEQ on a remote drive like that. I presume you can
LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the
OPENSEQ should work with that just fine. May I also presume that you looed
at FNAME and a file with that name really does exist in that directory file?
I'm pretty sure Universe can open windows SMB drives, but I don't know that
I ever tried it with other MV systems. Keep in mind the most important
thing about windows SMB drive shares: unless you are logged into the
desktop, it doesn't automatically map them. You may need to issue a net
use
...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: 05 August 2013 14:31
To: U2 Users List
Subject: Re: [U2] OPENSEQ
I've never used OPENSEQ on a remote drive like that. I presume you can LIST
LRGLBRVARS @ TCL without difficulty right? If so, I would think
] On Behalf Of Martin Braid
Sent: 05 August 2013 14:48
To: U2 Users List
Subject: Re: [U2] OPENSEQ
If you have LRGLBRVARS as a VOC pointer and can LIST LRGLBRVARS then OPENSEQ
'LRGLBRVARS',FNAME TO OUT.FILE ELSE NULL should do it if you know it is
present (if the XLS is open with Excel you
I could be wrong, but I seem to recall that OPENSEQ supports two syntaxes
Option 1 has 2 arguments: openseq voc.pointer, filename to ...
Option 2 has only 1 argument: openseq absolute.path.to.filename to ...
Also, if the server where your shared folder resides is not Windows, then
filenames
-1415
adew...@stylmark.com
www.stylmark.com
Stylmark is a proud member of RDI, ARE, NGA
You can now find Stylmark on LinkedIn and Facebook
-Original Message-
From: Kevin King [mailto:ke...@precisonline.com]
Sent: Monday, August 05, 2013 8:31 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
Does the code still fail with the dummy file out there? If not, I'd guess
permissions.
From: Al DeWitt adew...@stylmark.com
To: U2 Users List u2-users@listserver.u2ug.org,
Date: 08/05/2013 09:04 AM
Subject:Re: [U2] OPENSEQ
Sent by:u2-users-boun...@listserver.u2ug.org
Of
bradley.sch...@usbank.com
Sent: Monday, August 05, 2013 9:10 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
Does the code still fail with the dummy file out there? If not, I'd guess
permissions.
From: Al DeWitt adew...@stylmark.com
To: U2 Users List u2-users@listserver.u2ug.org,
Date: 08/05
.
-
-Original Message-
From: Martin Braid
Sent: 05 August 2013 14:52
To: U2 Users List
Subject: RE: [U2] OPENSEQ
Spot the spilling miss steak.
and that will of course be 202,FNAME
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org
Can someone point me to the page where we can use DIR type files at all?
It would make my job a lot easier!
-Original Message-
From: Al DeWitt adew...@stylmark.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Mon, Aug 5, 2013 7:04 am
Subject: Re: [U2] OPENSEQ
Thanks
- Original Message -
*From:* adew...@stylmark.com
*To:* U2 Users List u2-users@listserver.u2ug.org
*Date:* 8/5/2013 7:17 AM
*Subject:* Re: [U2] OPENSEQ
I'm a Domain Admin so permissions is not an issue. I'm going
Untitled Page
- Original Message -
*From:* adew...@stylmark.com
*To:* U2 Users List u2-users@listserver.u2ug.org
*Date:* 8/5/2013 7:17 AM
*Subject:* Re: [U2] OPENSEQ
I'm a Domain Admin so permissions is not an issue. I'm
, with full permissions.
Bill
Untitled Page
- Original Message -
*From:* wjhon...@aol.com
*To:* u2-users@listserver.u2ug.org
*Date:* 8/5/2013 10:16 AM
*Subject:* Re: [U2] OPENSEQ
*Falls out of my chair*
What ? What
the
writeseq?
Hth
Colin
-Original Message-
From: Al DeWitt
Sent: Monday, August 05, 2013 8:04 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
Thanks for your reply Kevin.
I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it.
FNAME does not exist. In the code I stole this from
...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke
Sent: Monday, August 05, 2013 12:32 PM
To: 'U2 Users List'
Subject: Re: [U2] OPENSEQ
Ummm, if the file doesn't exist then it's *supposed* to take the else clause,
when I'm creating new files I use THEN and put the abort
condition so you don't overwrite prior
logs.
-John
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Al DeWitt
Sent: Monday, August 05, 2013 11:03 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
As I mentioned earlier I
From: Al DeWitt
I'm a Domain Admin so permissions is not an issue.
I understand the sentiment there but we may not be aware of the
permissions required for the operation in question, so it's tough to
know if the right permissions have not been granted.
My related experiences, dunno if this
I don't know if we have enough information. Does it start? No output
whatsoever? IIRC, you can tell writeseq not to cache and to write to
disk immediately.
On Fri, Nov 4, 2011 at 3:03 PM, Holt, Jake jh...@samsill.com wrote:
I wrote a program to export some data using openseq/writeseq (to a
-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Friday, November 04, 2011 2:11 PM
To: U2 Users List
Subject: Re: [U2] OPENSEQ / WRITESEQ and UniObjects
I don't know if we have enough information. Does it start? No output
whatsoever? IIRC, you can tell writeseq not to cache
I'd guess it was some type of permission error. Does the user you are
connecting with through UniObjects have write permissions on the folder that
the open/writeseq is writing on?
hth
Colin Alfke
Calgary, Canada
-Original Message-
From: Holt, Jake
It fails to write. It gives the
] On Behalf Of Steve Romanow
Sent: Friday, November 04, 2011 2:11 PM
To: U2 Users List
Subject: Re: [U2] OPENSEQ / WRITESEQ and UniObjects
I don't know if we have enough information. Does it start? No output
whatsoever? IIRC, you can tell writeseq not to cache and to write to disk
immediately
It was a permission issue -- I blame Friday.
Thanks.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke
Sent: Friday, November 04, 2011 2:31 PM
To: 'U2 Users List'
Subject: Re: [U2] OPENSEQ / WRITESEQ
Please provide the exact source, and the exact compilation error message
-Original Message-
From: Al DeWitt adew...@stylmark.com
To: u2-users u2-users@listserver.u2ug.org
Sent: Fri, Oct 28, 2011 2:21 pm
Subject: [U2] OPENSEQ and the LOCKED Option
Unidata 7.1.20 ECLTYPE P
Whenever
I've usually only used it where I expect one user to be accessing the file
at a time anyway. However, it should (mine does on UD 7.1.6) compile. You
are using an END before the next THEN or ELSE - that might do it.
hth
Colin Alfke
Calgary, Canada
-Original Message-
From: Al DeWitt
-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Friday, October 28, 2011 4:39 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] OPENSEQ and the LOCKED Option
Please provide the exact source, and the exact compilation error message
-Original Message-
From: Al DeWitt
You need to change line 6 to END ELSE (to end the locked clause)
-Original Message-
From: Al DeWitt
Here is my admittedly simple test program and the results:
001: IMPORT.FILE = FILE_IN.CSV
002: CLOSE.IT = 1
That did it!
Thank you very much.
Al DeWitt
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke
Sent: Friday, October 28, 2011 5:01 PM
To: 'U2 Users List'
Subject: Re: [U2] OPENSEQ and the LOCKED Option
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
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
In message 321088.49154...@web36901.mail.mud.yahoo.com, Jacques G.
jacque...@yahoo.com 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
will it wait forever? Or will it halt the
system?
Try again later, answer fuzzy.
Will Johnson
-Original Message-
From: John Hester jhes...@momtex.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, May 18, 2010 12:31 pm
Subject: Re: [U2] OPENSEQ and Abnormal termination
...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
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
, ARGV_IN, ARGV_OUT)
This means each program calling MYSUB has to be modified.
- Original Message
From: John Hester jhes...@momtex.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, May 18, 2010 3:31:25 PM
Subject: Re: [U2] OPENSEQ and Abnormal termination of UV
Reading my
In message 536051.22442...@web36905.mail.mud.yahoo.com, Jacques G.
jacque...@yahoo.com 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,
Anthony W. Youngman pi...@thewolery.demon.co.uk
'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
.
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
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 FILEVARS1
would be.
-John
-Original Message-
From: u2-users-boun
!! ??
-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
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
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
-
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
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:
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
u2-users-boun...@listserver.u2ug.org
To: u2-users@listserver.u2ug.org u2-users@listserver.u2ug.org
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
-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
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
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:
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
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
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
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
Thank you all. It is working now with the VOC pointer. It is much
simpler now that I don't care what account I'm in.
One final question.
I have downloaded many of the pdfs ( UniBasic command ref., Using
unidata, SB+ Solutions, ...) from the IBM site but where is this
documented? Are there any
*
==
Allen E. Elwood
www.tortillafc.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Timothy Snyder
Sent: Wednesday, January 04, 2006 19:12
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] openseq
Jeff,
AFAIR OpenSeq on UniData looks for either a path name, or if you specify an
item id it looks for an item in a directory file (not a path).
So you would need to either
A) OPENSEQ /tmp/ : MTR.REC TO F.MTR.ROW.FILE ...
Or
B) create a file pointer to /tmp (e.g. named TMP) and then
Is it a permissions problem?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jeff Powell
Sent: Wednesday, January 04, 2006 8:31 AM
To: u2 users group
Subject: [U2] openseq question
Happy New Year.
I am having trouble with the openseq function in UniData.
Jeff,
I think Openseq looks either for a fully specified path to the file as in :
OPENSEQ /tmp/recordname TO F.MTR.ROW ELSE
or it understands the filename, recordname construct but looks for the
filename in the VOC, as in
OPENSEQ TMPFIL, recordname to F.MTR.ROW ELSE...
where TMPFIL is a DIR
No. /tmp is an absolute path.
On Wed, 2006-01-04 at 09:47 -0500, Koser, Mike wrote:
Jeff
Is '/tmp' in the VOC?
Mike
-Original Message-
From: Jeff Powell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 04, 2006 9:31 AM
To: u2 users group
Subject: [U2] openseq question
Your syntax is a little off. When you use the seq.file.name, record.id
syntax then seq.file.name has to be a dir type file. You will have to
either create a voc entry for /tmp, eg.:
TMP.DIR
001 DIR
002 /tmp
003 D_VOC
And then you should be able to: MTR.FILE.PATH = TMP.DIR
Or you can OPENSEQ
You need to have MTR.FILE.PATH open as a file handle, first. You can do
one of the following:
MTR.FILE.PATH='/tmp'
OPEN MTR.FILE.PATH TO MTR.FILE ELSE STOP
MTR.REC = 'RECID'
OPENSEQ MTR.FILE,MTR.REC TO F.MTR.ROW.FILE ELSE
[what you already have]
END
Or open the full path directly:
I've actually had problems with various versions of Unidata and
CLOSESEQ releasing the file when opening a full path. Opening under a
VOC DIR-pointer has never exhibited that problem, so I'd recommend the
VOC pointer approach over using a full path.
-Kevin
[EMAIL PROTECTED]
Several years ago I created a little utility to open sequential files as
needed. It's pretty robust; hasn't given me much trouble over the years.
Like Kevin, I've had problems with the full path version of openseq, so my
utility converts full path mode to VOC pointer mode and creates the VOC
I've always found it helpful to open the file/record in 'regular' mode first
to find out if the directory entry worked or possibly to write a null record
if it didn't.
I like to have a graph display, and this way I can tell how many 'records'
(or AMCs in this case) I'm going to be processing so I
] On Behalf Of Kevin King
Sent: Wednesday, January 04, 2006 9:36 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] openseq question
I've actually had problems with various versions of Unidata and
CLOSESEQ releasing the file when opening a full path. Opening under a
VOC DIR-pointer has never
Thank you for all your helpful suggestions.
I am now looking at creating a VOC pointer as Kevin suggests below.
Actually I'll need to create two pointers one for the TEST account and
another for the LIVE account.
I had originally tried the PATH:FILE syntax before I found out that the
file needed
Do you recall which OS this was on? I don't believe I've run into
this problem but I'm currently using Windows (2000 and 2003) but I've
also been on RS6000 and DG/UX. All of this is with UV.
Unidata on Windows, as I recall.
-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
---
u2-users
Jeff;
I use a VOC pointer for exactly this reason. It doesn't matter which
account/where the directory is - I just need the VOC pointer that points
to it. It makes it really easy to transfer from TEST to LIVE.
Also, as Tim pointed out, you don't need the file to exist to open it.
In fact, I have
Unidata on Unix has this issue, too (at least the DEC Tru64 flavor) -- it holds
onto the file lock after CLOSESEQ of a file OPENSEQed with the Unix path.
Don't know if it's been fixed in newer UD releases, but not likely a priority
since OPENSEQ of a VOC pointer doesn't have the problem.
Actually I'll need to create two pointers one for the TEST account
and another for the LIVE account.
This is one of the great features of the VOC pointer; the LIVE account
can point to the directory it needs and the TEST account can point to
the directory it needs and the program doesn't have to
Thanks again to everyone for all their help. I'm almost there.
I want to use the VOC pointer so I created the pointers in my Live and
Test VOC files, logged out and back in to ensure I was reading VOC but
I'm still not meeting with any success. When I attempt to reference the
pointer I get a
Jeff, if the VOC entry is MFG.DATA.IPS.TMP then the OPEN is:
OPEN MFG.DATA.IPS.TMP, MTR.REC TO ...
Not the concatenated thing you had in your post.
-K
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Jeff Powell wrote:
Thanks again to everyone for all their help. I'm almost
there.
I want to use the VOC pointer so I created the pointers in
my Live and
Test VOC files, logged out and back in to ensure I was
reading VOC but
I'm still not meeting with any success. When I attempt to
reference
Allen E. Elwood wrote on 01/04/2006 01:29:47 PM:
I've always found it helpful to open the file/record in 'regular' mode
first
to find out if the directory entry worked or possibly to write a null
record
if it didn't.
So, if the O/S-level file is multi-megabytes, you're reading the whole
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder
Sent: Thursday, 5 January 2006 1:42 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] openseq question
Allen E. Elwood wrote on 01/04/2006 01:29:47 PM:
I've always found it helpful to open the file
I would think that you have actually gone over the file size limit of
Linux ... tail head may not REALLY be working (accurately).
I actually thought the limit was 2Gb (which is why the need for
partitioned files in the first place).
Happy to be wrong (not an active UD user), but had a similar
Ross Ferris wrote:
I would think that you have actually gone over the file size limit of
Linux ... tail head may not REALLY be working (accurately).
I actually thought the limit was 2Gb (which is why the need for
partitioned files in the first place).
Happy to be wrong (not an active UD
76 matches
Mail list logo