I have used a routine previously suggested called WhatHaveIGot, which
determines the type of a variable and if it is a file variable it returns
the name of the file.

This is an excellant routine BUT...

The description of the user exit "U90" says that it returns the file number
in FOF of the last file process performed in the program prior to "U90".
Unfortunately I have just been advised that any FSI file numbers are stored
in the FSIDM,FILEOFFILES file and not FOF in DM. The "U90" routine returns
blank for these files - I assume that is because it only checks the DM FOF.

Is there any user exits that check the FSIDM FILEOFFILES? Just had a
thought, I will check if the U90 is able to check the FOF (q-pointer) when
it points to the FSIDM file.

Best regards,

Neil.

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

Changing the FOF in the MD did not work.

Does anyone know the reason for the FSI files being stored seperately? Is
there any reason why I should not copy the FSIDM,FILEOFFILES list into the
original FOF?

Best regards,

Neil.


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

Every time you access a VME file, the system does so by loading three fields
in your PCB: BASE, MODULO, SEPARATION. Then it calls Retix and Hash and
find where your item is.

U90 works, because the instruction before that somehow massaged BASE. By
definition, FSI files don't have a "base" because they are not really stored
in frames. There is no base frame so this can't work.

I thought the original post only wanted to know IF the variable in question
was a file variable, not necessarily to which file it's attached. I got the
impression they didn't really know WHAT the variable was and werr just
trying to find some code trick to keep from having to figure it out. If
they need to know which file it's attached to, the next question is how
often do you need to know? Once, or every time you run the program.

I'm sorry, but if you have a program and you don't know what the variables
are for, maybe you need to think about a career in the food service
industry.


Mark Brown


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

Mark Brown wrote:
[snip]
LMAO! "Would you like FSIs with that?"

--
frosty

Mark,

Thanks for your explanation about the methodology for D3 file handling
within a basic routine.
"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

within a basic routine.

I know U90 doesn't work, hence my question "Is there any user exits that
check the FSIDM FILEOFFILES?"

If you read the original post, I asked for an equivalent method as I have
with the IOCTL option in jBASE which allows me to get the filename as well
as determining if a variable is a filevar or not.

Meeow! Again, if you read the original post I am dealing with programs that
are firstly not my own and secondly there is no source available. In fact
this is slightly inaccurate as well as, I was trying to avoid any kind of
advertising as I know it irritates people.

I am dealing with source code that has been created by developers in SB+ and
System Builder, for which the OSMOSiS 4GL has conversion tools. Every
programmer seems to have different rules and standards and use variables for
vastly different purposes. One of the functions in OSMOSiS is to save the
common area and whilst I know exactly what my variables are used for, I do
not know how other developers are going to use them. Now I can save the
common area by checking the variables to see if they are filevars or not,
blank out the filevars and then writing to a disk file OR I can do what I do
with jBASE and that is to check for filevars, get their names, blank out the
variables but save their names and then if and when the common block is
restored I can open them all thus retaining the full integrity of the common
block.

BTW the common block I am referring to is not the carving block, knife block
or any other kitchen utensil :-)

Best regards,

Neil.

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