Hi

I've been using OPENSEQ and WRITESEQ successfully to create delimited
OS files. It doesn't matter that the ELSE clause is taken on the
OPENSEQ because I still get a file variable assigned (and STATUS()
returns a zero) and I can go ahead and do WRITESEQs.

I thought changing to use OSOPEN and OSBWRITE would be trivial - but
not so apparently. When the ELSE clause is taken on the OSOPEN (when
trying to open/create a brand new file) the file variable is left
unassigned so that subsequent OSWRITEs fail. Am I expected to PCPERFORM
a mkfile or something? There doesn't seem to be anything to guide me in
the UniData manuals, here in comp.databases.pick or in the u2users
searchable archives.

Mike.

There's an EXISTING option in mvE for OPENSEQ and what that does is
that if the file you're trying to open doesn't exist, it creates it.
But since you're using Unidata, I don't think there's something similar
there.
What I suggest is you examine your STATUS at the end of the OSOPEN and
then if it tells you the file doesn't exist go and touch it.

jak

Thanks for the reply jak.

What I meant to say in my OP was "...subsequent OSBWRITEs fail". Scary
then that the solution I hit upon (shortly before your reply showed up)
was to use OSWRITE "" to create the non-existant file - because OSWRITE
doesn't need a file variable and writes to a file name, or path. I
didn't know OSWRITE actually existed when I made my typo. I don't know
if it's better or worse than PCPERFORMing a touch, but it seems to work
fine. I never did like Unix much - and creating something simply by
touching it is one of the things I find counter-intuitive. Perhaps my
aversion to Unix also explains my relative unfamiliarity with the U2
products - I'm more at home with the R83/D3/Reality...etc side of the
MV family. Still - each branch has its good points.

Cheers
Mike.

I trust that the UniBasic Commands Ref manual is wrong when it gives
the following example:

OSBREAD TEST FROM 'RFILE' AT 0 LENGTH 10000

in that it also states:

Note: Before you use OSBREAD, you must open the file by using the
OSOPEN or OPENSEQ command.

so that, logically, if we're required to open a 'file' to a
file.variable then we would also be required to use the file.variable.

Also - OPENSEQ has a LOCKED clause. OSOPEN doesn't. What happens if two
or more processes OSBWRITE blocks of data to the same OS file (like
UniData record) at the same time? Is that what the ON ERROR clause is
for?

Also - the manual says that WRITESEQ doesn't actually write data to
disk, that it writes to a buffer, and that we should use WRITESEQF if
we want to force the update to disk. I can therefore understand that
CLOSESEQ must flush the buffer to disk too. Does
OSOPEN/OSBWRITE/OSCLOSE function similarly? Shouldn't there also be a
OSBWRITEF in that case?

Mike.

PS. I miss D3 and JS's excellent documentation ;P