Have I got this right...?

If I do an OPENSEQ followed by one or more READSEQs, the current record
pointer will be set to where the latest record just read terminated.

If I do a WRITESEQ with an APPEND option then regardless of where the
current pointer is positioned the data will be appended to the end of
the file and the pointer will move to EOF.

If I do a WRITESEQ with no APPEND option, and the current pointer is
anywhere other than at EOF, the write will fail and the ELSE clause
will be taken.

The system might be maintaining a current record pointer but it's only
ever relevant when you're READSEQing.

You might as well always use the APPEND option anyway when you're
WRITESEQing.


It is simply not possible to do the equivalent of a WRITEV, unless you
get all complicated about it and have a before and after image,
READSEQing from before-image and WRITESEQing to after-image, and
PCPERFORM a !mv of after-image over before-image afterwards.

I hope I'm missing something and that is it possible to simply update a
line in the middle of a sequential file after all.

Did someone say something recently about booze and dancing? I just
gotta get back to the Sierra Hotel.

Mike.

I've thought about this some more and will be adding WRITEV equivalent
capability for sequential files to the ASCII.FILE code. It's another of
those cases where the tools you want aren't in the box so you have to
go make them yourself. OK - so check the box with "QuickestSort" on the
cover... coming to mvdevcentral some time soon...

Mike.

Just be carefull you do not put so many tools in the box that no one
knows the best way of doing anything!

Yes, I think you have this write

I've used writeseq a lot to create txt files to be loaded into other
systems. Lately I've been using it a lot to export UniData files to SQL
databases. It's very good (and fast) at dumping out data. I've done some
limited testing against using the OSB... commands and unless you have the
parameters optimized the ...SEQ commands are faster - and they're not that
much slower of the OSB... commands are optimized.

However, I think you're missing the point of the "SEQ" part of the command.
I think it's short for SEQUENTIAL - so a writev is not really what it's
meant for, as really that's random access to the file.

The easiest way around this: simply define a DIR file in the VOC pointing to
the directory that you are working in. Then you can read/matread the item,
update, writev etc as required. Of course, if this is a binary file this
technique won't work so well, but then, I'm not sure the ...SEQ commands
would work well with binary files.

hth
Colin Alfke
Calgary Canada

<michael> wrote

Hi Colin

Yes - look at the SEQ..., focus on the Q and see an old 1/2" tape reel.

Still...

<quote from page 4-21 of the UniData manual "Developing UniBasic
Applications">
UniData Hashed File Commands
You can use hashed file commands (OPEN, READ, WRITE, CLOSE, and DELETE)
on non-UniData sequential files that have VOC entries. However, we
discourage this practice because UniData could, in some cases, insert
characters in the file, even upon opening it. Use the sequential file
commands listed earlier, or operating system commands
</quote from page 4-21 of the UniData manual "Developing UniBasic
Applications">

I've had my nose stuck in the UniData manuals quite a lot lately. Not a
pleasant experience I can tell you - so bad at times in fact that the
thought has occurred to me that maybe UniData ought to have a leading
"D". "DUniData", "DUniVerse"... no - probably wouldn't help sales
downunder much. You never know though..<g>

Regardless of whether you can trust the manuals or not, working with
SEQ files as SEQ files rather than as hashed files makes good sense. No
need to manipulate (huge) strings or arrays in program memory. I'm
totally convinced that using SEQ files and UNIX commands is the way to
go when sorting an array (Pick multivalues within attributes or any
other kind), for instance, and especially if the !sort is in a "black
box". Using UNIX commands, it shouldn't be too difficult to manipulate
SEQ files any way we want - including readv/writev equivalents - and if
it's all done in a "black-box" subroutine then all the better I say (I
tend to think most UNIX commands are so ugly that putting them in a
black box is entirely appropriate).

As for binary files (containing char(255) and/or char(0)) - the
OSBREAD/OSBWRITE instructions are there to be used, although I haven't
had any call to use them yet.

Cheers
Mike.

PS. WEOFSEQ does truncate the file where you're at, allowing you to
WRITESEQ over what was there, but that's rarely going to be much help.

PPS. FILEINFO({FILEVAR},14) is useful in that it tells you the next
line number due to be READSEQed (where the first line is line 1 - not
line 0).

Some further thoughts...

I'm sure we've all had occasion to deal with large dynamic arrays in
program memory - and perhaps suffered because the strings we're dealing
with have grown too large to deal with efficiently.

Sorting is one example - when you locate keyfield1 in an array of
attributes (in DIMARR(1) say) setting pos1, then keyfield2 in an array
of multivalues (DIMARR(2)<pos1>) setting pos2, then keyfield3 in
subvalues (DIMARR(3)<pos1,pos2>) setting pos3, etc.. Maybe we want also
to accumulate totals associated with each "break-level" as we go (so
that we only need to pass through a selected input list once). There
will be other things you might want to do with large strings/arrays too
- only we've become used to the constraint that trying to do too much
in program memory becomes impracticable.

I'm thinking it should be possible to do this efficiently by moving the
large strings out to the OS file space. The main stumbling block with
this approach is that you can't easily insert/delete data in the middle
of an OS sequential file using the ...SEQ (U2), or %... (D3), or
whatever they are, commands in your Pick/MV flavour of choice.

We've also been content to accept that we can only use LOCATEs,
INSERTs, DELETEs, etc., down as far as subvalue level. Is there any
good reason why we can't continue on down from char(254) through
char(253)... all the way down to char(128) - at least while we're
working on the data?

What I'm getting to is an efficient, easy way round these constraints -
by using the underlying OS's commands to do the tricky stuff in a
"black box" subroutine. Might even make XML>MV and MV>XML data
conversions that much easier. I've made a start with the ASCII.FILE
subroutine in the QuickestSort project on mvdevcentral. Anyone want to
lend a hand? Someone with superb UNIX scripting skills would be handy.

Cheers,
Mike.