MFS Setup for Stand-alone apps (OpenInsight 64-bit) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>category:"OpenInsight 64-bit" author:"Brad Bishop" author:"Donald Bakke"}}

[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]


==== MFS Setup for Stand-alone apps (OpenInsight 64-bit) ====
=== At 24 NOV 2021 10:09:30AM Brad Bishop wrote: ===
 
 
<QUOTE>
My development environment consist of one server and a single instance of Open Insight V10.1 with multiple apps.  Each app is standalone and does not inherit from any other app.  Within each app there are multiple tables that have MFS’s.  Each MFS consists of a stub module that calls the actual MFS.  The MFS is setup on the table as MFS_TABLE_STUB@APP where the module MFS_TABLE_STUB is simply a pass through to module MFS_TABLE.  This allows changes to be made to the MFS without having to remove\add the table to refresh the MFS.  



What I am experiencing is that each of the MFS’s (not the stubs) must be added to SYSPROG or a program not found error is generated when signing into the app.  I believe this is because the tables are being attached before the code inheritance is established.  To resolve this, I have to add the MFS_TABLE module to SYSPROG with the subroutine header and a return.



Three thoughts:  1) Is it possible to change the startup sequence so the code inheritance is established before the tables are attached?  2) Is there a method of calling a stored procedure with a designated app?  3) Do I have to develop a module that does the table attachments within each app rather than have Open Insight do the attachments ?  I have tried setting up the MFS name as a variable within the stub and calling it as @mfs_name but that did have any effect on the error message generation.



While this is not a showstopper for my installations having to add modules at the SYSPROG level breaks the desired model of each app being a self-contained unit.  If I was developing apps to sell on the retail market this would be a huge issue as the SYSPROG environment should never be updated.  Is there something I am missing in how I have the MFS’s or APP setup?


</QUOTE>
----

=== At 24 NOV 2021 10:22AM Donald Bakke wrote:  ===

<QUOTE>
<QUOTE>My development environment consist of one server and a single instance of Open Insight V10.1 with multiple apps.  Each app is standalone and does not inherit from any other app.  Within each app there are multiple tables that have MFS’s.  Each MFS consists of a stub module that calls the actual MFS.  The MFS is setup on the table as MFS_TABLE_STUB@APP where the module MFS_TABLE_STUB is simply a pass through to module MFS_TABLE.  This allows changes to be made to the MFS without having to remove\add the table to refresh the MFS.  



What I am experiencing is that each of the MFS’s (not the stubs) must be added to SYSPROG or a program not found error is generated when signing into the app.  I believe this is because the tables are being attached before the code inheritance is established.  To resolve this, I have to add the MFS_TABLE module to SYSPROG with the subroutine header and a return.



Three thoughts:  1) Is it possible to change the startup sequence so the code inheritance is established before the tables are attached?  2) Is there a method of calling a stored procedure with a designated app?  3) Do I have to develop a module that does the table attachments within each app rather than have Open Insight do the attachments ?  I have tried setting up the MFS name as a variable within the stub and calling it as @mfs_name but that did have any effect on the error message generation.



While this is not a showstopper for my installations having to add modules at the SYSPROG level breaks the desired model of each app being a self-contained unit.  If I was developing apps to sell on the retail market this would be a huge issue as the SYSPROG environment should never be updated.  Is there something I am missing in how I have the MFS’s or APP setup?

</QUOTE>



Brad - Does this [url=https://www.revelation.com/revweb/oecgi4p.php/O4W_RUN_FORM?INQID=WORKS_READ&SUMMARY=1&KEY=19644.55691%2AAD2209CEDFD1ED479FE1499604300EAB#/section/breadcrumb/UPDATETABLE/Display]thread[/url] address your issue?



[url=mailto:dbakke@srpcs.com]Don Bakke[/url]

[url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url]

</QUOTE>

----

=== At 24 NOV 2021 10:39AM Brad Bishop wrote:  ===

<QUOTE>I add the code clip to the stub module and it worked like a champ.  Thanks for the help.  Evidently I didn't realize the utility of the code clip until I needed it.   



ps. I also resolved the previous issue with the MFS's.  When they were originally developed (long before I worked on these systems) the call to next.mfs was missing in several places.  Hence sequencing of the MFS's had an impact what got executed.



Thanks again !!

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=5DFF2CA1A4B7EC4384B768DE9AE9B6BD|View this thread on the Works forum...]]