I have a system written by someone and I need to save the COMMON area to
disk. Now, most of the area is predefined so I know what is and what isn't
a file-variable. Some variables within the COMMON block are user-defined
and can be used for anything including file-variables.

In jBASE I can use the IOCTL function and get the filename of any variable,
which also returns 1 if the var is a filevar but 0 if it is not.

This allows me to determine which variables are filevars and assign those to
blank but also to store the file name and COMMON variable array number so
that if I restore the COMMON block from disk I can reopen the correct files
to the correct COMMON arrays.

My question is: are there functions in D3 and UniVerse BASIC that will allow
me to achieve the same (or similar) functionality.

Before someone says that I should check the source code, there are some
routines that I do not have the source code to.

Thanks for your help.

Best regards,

Neil.

Neil Charrington
S C Systems
T: +44 1564 777011
F: +44 1564 777454
W: www.sc-sys.com

For D3 you could google cdp for WhatHaveIGot

Cheers
Mike.

michael (AT) preece (DOT) net wrote:
Hmmm, if you don't have a file variable and you use it as part of a
Read, you get a run-time abort. The code to which you refer has an
"else debug" clause for that. Neither result is desirable in
production code. Up until that point the code is ok, but that's
exactly the part that Neil needs. I'm not aware of any complete
solutions to this problem as-yet.

T

Just checked uv10, which has a STATUS var instruction with both an ELSE and
an ON ERROR clause.

So I'd expect STATUS s FROM [anyvar] ON ERROR {or ELSE} [not a filevar]
would work.

Guess what? The brain dead system designers at uv give a fatal error and
drop directly to TCL (!!!!). Does not correspond to documentation, either,
which says only a NULL value causes a fatal error (why!? this would make it
useless also) but in any case, Neil, no can do on uv.

Chandru Murthi

"Neil Charrington" <neil (AT) casoftware (DOT) co.uk> wrote

"Neil Charrington" wrote
{asking if D3 and UniVerse BASIC allow you to detect if a common block variable
is a handle to an opened file -- this is in support of a project lacking source code}

Dunno about UV, but D3 won't let you find this out without crashing the program.

This might be a job for C if you're doing this in D3, and in particular D3 on top of
linux/unix/etc instead of windows, then you might write your own C program and
add it to the monitor; I'd have to guess you'll find it much cheaper to buy a
third-party BASIC decompiler and learn from the resulting source code. And
BASIC doesn't have a PEEK in D3.

Sadly, both foo=3
and OPEN 'md' TO foo ELSE null
cause the D3 function ASSIGNED(foo) to go true, so no help there.

Our D3 gave a stack error when I tried copying a file handle to another variable then
doing an IF (a = myfile) THEN crt 'same' -- a fine example of a compiler bug too
trivial to fix.

murthi wrote:
UniVerse 10 has the FILEINFO function.

$INCLUDE FILEINFO.INS.BAS
If FILEINFO(FILE.VAR,FINFO$IS.FILEVAR) THEN
PRINT 'THIS IS A VALID FILE VARIABLE'
END ELSE
PRINT 'THIS IS A STANDARD DATA VARIABLE'
END

The include file contains equates for 22 types
of info relating to UniVerse files.

Ron White

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

A stack error isn't a compiler error, it's a run time error.

The compiler could care less what the various variables will hold even if it
could know.

Run time sets a flag on every entry of the descriptor table telling what
that variable is, the closest thing traditional Pick has to data typing.
Most of the time id doesn't care so you can play with list variables to some
extent, but with file variables, it's different. They're binary, so you
can't treat them like strings; there's nothing at the adress they point at
that would be interesting, and realistically, what would you ever want to do

And, ultimately, someone somewhere made a decision at some point that there
was nothing you would ever WANT to do to a file variable, therefore you
CAN'T do anything with it.

Mark Brown

"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

Hmm, Mark, you just gave me an idea. If we %malloc space and copy a
file descriptor to that space, then we should see binary data, maybe
leading with x01, whereas a normal var would have its value inserted
into the memory space. This is assuming that the %functions won't
choke on use of a file descriptor being used, like the BASIC runtime
chokes on other instructions - but %functions aren't processed by the
BASIC runtime. Do you think this is worth a try? This could all be
resolved down to a small subroutine which returned IS.FILE=0 or 1, and
might be extended to return other info like Mike P's proggie.

T

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote:

This can only work if you know the offset in the descriptor table for any
particular variable. They are inserted in the order they are found, but in
some programs, that's a nightmare. You would never be able to say

is.file(var)

because the PUSH process will choke trying to push the variable onto the
stack. Another poster in this thread mentioned that. Hmm, unless is.file
looked like a subroutine, I just don't know.

I do know only difference between a file variable and a long string variable
is that first byte, so just looking at the data isn't always a good check
unless you have some static data that you can key on.

Mark


"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

You may want to do what the OP asked for.

Yeah, the decision was made by default, so to speak, ie, it fell out of the
loop of legal pushable variables, except when needed as in READ. But as it's
still this way, it's is an example of why systems programmers should be
forced to write an application every now and then (say, maybe we need to
have a license to write systems and this could be a requirement). After all,
in mvE, R91 and Ultimate etc fv's are treated as something manageble. It
would be a trivial runtime change.

Chandru Murthi