- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The approach usually used is to convert the program to a DLL with routines that can be called by the main program. If this DLL is invoked by different EXEs or different runs of the same EXE, each DLL's data will be separate.
If instead you have a single EXE that wants to call these functions in different contexts and with separate data, that's a bit harder. First, you must add the keyword RECURSIVE to every subroutine or function, or compile with the /recursive option. Second, do not use COMMON or module variables or SAVE or variables that are given compile-time initial values. Third, keep context data in a variable that is allocated and passed back and forth.
A more daunting approach is to create a COM server DLL out of your program - this will make it available to C++, VB.NET and C# as one or more "methods". I don't recommend this unless you're really up on COM, but if you do try it, you'll be using the Fortran COM Server Wizard to get started.
I hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I take the DLL route, isn't there an issue with unit numbers? Aren't all unit numbers the same for each DLL? We open and close many files during each run, with some open the entire run. Will there be conflicts since each DLL will be using the same unit numbers at the same time?
We actually would like to build a separate DLL for each run since the logic within the each run can vary. My thoughts were to compile andstart each DLL running in a different thread, each using its own set of data that would be read from input files, and actually contain slightly different code. Many of the solution routines are the same, but with slightly different routines in each DLL. But IO is the main concern and how that works.
For cases where the logic is all identical, and only some input variables change, wouldCOARRAYS be a good alternative? It seems that would take a considerable amount of source changes, where different DLL's wouldn't really require any differences. And we make extensive use of both common blocks and modules.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Coarrays don't sound like a good fit for you. That's when you have a single set of data that you want to act on in pieces and in parallel.
It sounds to me as if you might be better off keeping the program as an EXE and invoking it using CreateProcess or ShellExecute, with some sort of input parameter file specified for each instance that tells it what to do.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does the NEWUNIT option recycle the file number as soon as a file is closed? Sounds like you would have to use NEWUNIT for every open statement, since if some opens used spefic unit numbers,and that number was picked by NEWUNIT and then you could get a file already open error. True?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page