OI 10.1 beta

I just started recreating my mfs procedures again

I have the create procedure where the mfs gets added in sysprog, and this is called when i add a table to use the mfs.

however the procedure that intercepts the read write etc is in the actual database I am working on

when I start OI it says the procedure is "missing" and logs me off

so I have to create it in sysprog as well (not same in V9.x)

when using it the system seems to use both procedures at different times

I know because there is a debug in both in different places

what am I doing wrong?

as I don't really want to keep changing the procedure in Sysprog all the time

Thanks

Gerry

OI 10.1 beta

I just started recreating my mfs procedures again

I have the create procedure where the mfs gets added in sysprog, and this is called when i add a table to use the mfs.

however the procedure that intercepts the read write etc is in the actual database I am working on

when I start OI it says the procedure is "missing" and logs me off

so I have to create it in sysprog as well (not same in V9.x)

when using it the system seems to use both procedures at different times

I know because there is a debug in both in different places

what am I doing wrong?

as I don't really want to keep changing the procedure in Sysprog all the time

Thanks

Gerry

Gerry - If you think this is a 10.1 beta specific issue then you might want to post this question in the beta forum.

Don Bakke

SRP Computer Solutions, Inc.

Not Sure

Probably not a 10.1 issue

but a 10. issue

Gerry

Not Sure

Probably not a 10.1 issue

but a 10. issue

Gerry

I have an application running in 10.1 Beta that uses several MFS routines but none of them are calling an external routine during the CREATE.FILE primitive. Thus, it will take a bit of effort for me to replicate your situation. However, if, as you say, your OI 9.x system does not have any problems calling your external routine whereas OI 10.x does, then it would seem that the call to the MFS is happening prior to the database being fully swapped. That's just my SWAG without knowing more.

We generally store our MFS routines in SYSPROG but we also tend to store any called routines in SYSPROG as well just to avoid these kinds of issues. If your called routine will always be in the same child application, then you can try this:

Routine = '[i]MyRoutineName[/i]*[i]MyChildApp[/i]'

Call @Routine([i]Param1[/i], [i]Param2[/i], etc.)

Even if this problem precedes 10.1 beta, you should still report it in the 10.1 beta forum or bug tracker since that is the next version where this might be fixed (assuming a fix is required).

Don Bakke

SRP Computer Solutions, Inc.

I also ran into this. I resolved it by moving all the MFS's (stubs and workers) to the application level. Then I manually added the MFS's to the table dictionary. I qualified all MFS's to the application (MFS_TABLE_STUB*APPLIC). I also found that SI.MFS has to be the last value in the MFS string. This can bite you when you add the first index to a table that already has an MFS. If you do this you can manually edit the table dict and move the SI.MFS to the last value. (It would be nice if the system added SI.MFS at the end, but it adds it in the front)

Finally make sure that none of the application tables are attached at the SYSPROG level.

bb

Finally make sure that none of the application tables are attached at the SYSPROG level.

Good advice.

You are specifying the key to sysobj so the oi can call@(mfsname, fs, handle, id,fmc,record,status). As long as you specify the mfsname*appname the mfs should load correctly from any application. But it the mfs has dependencies on other application-specific programs then the mfs can only run in that application.

It would be nice if the system added SI.MFS at the end, but it adds it in the front

You can call set_mfs with a parameter to force the location of the mfs. For example

call set_mfs( "MYTABLE", "MY_MFS*MYAPP",2)

will put the mfs at the front.

The values are

equ ADD_END$		to 1	/* Add to the end (just before BFS ) */

equ ADD_FRONT$		to 2	/* Add to the very front (if possible) */

equ ADD_POST_SYS$ 	to 3	/* Add as close to the front as possible */

equ REPLACE$		to 4	/* Remove all existing and replace */

equ REMOVE$		to 5	/* Remove the list of MFSs from the table */

equ CLEAR$		to 6	/* Remove all MFSs from the table  - setMFSList is ignored */

OI 10.1 beta

I just started recreating my mfs procedures again

I have the create procedure where the mfs gets added in sysprog, and this is called when i add a table to use the mfs.

however the procedure that intercepts the read write etc is in the actual database I am working on

when I start OI it says the procedure is "missing" and logs me off

so I have to create it in sysprog as well (not same in V9.x)

when using it the system seems to use both procedures at different times

I know because there is a debug in both in different places

what am I doing wrong?

as I don't really want to keep changing the procedure in Sysprog all the time

Thanks

Gerry

And this works exactly the same way in 9.x?

I'm not sure what procedure you're referring to. Is this a procedure that your MFS calls?

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

I also found that SI.MFS has to be the last value in the MFS string.

In what sense does it have to be the last value? Are you saying OI requires this or that it is simply preferred?

Don Bakke

SRP Computer Solutions, Inc.

Not Sure

Probably not a 10.1 issue

but a 10. issue

Gerry

I have an application running in 10.1 Beta that uses several MFS routines but none of them are calling an external routine during the CREATE.FILE primitive. Thus, it will take a bit of effort for me to replicate your situation. However, if, as you say, your OI 9.x system does not have any problems calling your external routine whereas OI 10.x does, then it would seem that the call to the MFS is happening prior to the database being fully swapped. That's just my SWAG without knowing more.

We generally store our MFS routines in SYSPROG but we also tend to store any called routines in SYSPROG as well just to avoid these kinds of issues. If your called routine will always be in the same child application, then you can try this:

Routine = '[i]MyRoutineName[/i]*[i]MyChildApp[/i]'

Call @Routine([i]Param1[/i], [i]Param2[/i], etc.)

Even if this problem precedes 10.1 beta, you should still report it in the 10.1 beta forum or bug tracker since that is the next version where this might be fixed (assuming a fix is required).

Don Bakke

SRP Computer Solutions, Inc.

I created a test environment using OI 9 and OI 10 to see if there is a difference. Both environments produced an RTP27 runtime error when the local procedure was called. This is what I would have expected. I am curious about your claim that this works in your OI 9 but not in OI 10.

Don Bakke

SRP Computer Solutions, Inc.

I also found that SI.MFS has to be the last value in the MFS string.

In what sense does it have to be the last value? Are you saying OI requires this or that it is simply preferred?

Don Bakke

SRP Computer Solutions, Inc.

In theory, it shouldn't t matter where in the chain any MFS is placed. In practice, it can make a huge difference. For example, if you have an encryption MFS, that should probably be last, otherwise you'll index encrypted data. On the other hand, if the MFS determines that an email needs to be sent, then it probably doesn't matter where the order is.

Basically, SI.MFS needs to in the correct place in the chain depending on whether you want to index what you see or index what you write.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

I also found that SI.MFS has to be the last value in the MFS string.

In what sense does it have to be the last value? Are you saying OI requires this or that it is simply preferred?

Don Bakke

SRP Computer Solutions, Inc.

In theory, it shouldn't t matter where in the chain any MFS is placed. In practice, it can make a huge difference. For example, if you have an encryption MFS, that should probably be last, otherwise you'll index encrypted data. On the other hand, if the MFS determines that an email needs to be sent, then it probably doesn't matter where the order is.

Basically, SI.MFS needs to in the correct place in the chain depending on whether you want to index what you see or index what you write.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

Yes - exactly - but I am curious if Brad is running into something else that might indicate a poorly designed MFS that doesn't play nicely with others.

Don Bakke

SRP Computer Solutions, Inc.

Anytime the SI.MFS was not in the last position reads to the table would return no data. When SI.MFS was moved to be the last one called data was always returned.

Anytime the SI.MFS was not in the last position reads to the table would return no data. When SI.MFS was moved to be the last one called data was always returned.

Then something is wrong with the other MFS. It shouldn't matter.

We have a client with a complicated statutory auditing requirement. The auditing MFS is on probably 40 files, maybe more. While most files have SI.MFS first, there are a few where it's at the end. All indexing and auditing work fine.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

When in the SYSPROG application you can not call subroutines that are not in the SYSPROG application, I do believe this is so.

I have run into an issue with an MFS where it tries to call a subroutine from another application. It reports that the object code was not found.

To avoid this error I simply put code before the call subroutine in the SYSPROG MFS that does the following…

IF @APPID EQ 'SYSPROG' THEN

  STATUS = TRUE$

  RETURN

END

This works for me.

View this thread on the Works forum...