Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
49 Views

Wrapping Fortran Programme to replace Card based I/O

Hello,

Apologies if this question has been asked before, but I couldn't find anything related in the forum.

My question is, is it possible to write a Fortran wrapper code to wrap around a legacy Fortran programme to handle the I/O to this programme that was originally written to handle I/O from cards?

I have a very old legacy Fortran programme written in the 1960's which uses WRITE and READ statements to read and write information to and from NIN, NOUT and NCARD. I would like to create a wrapper script around this code, to replace the inputs and outputs so that I can then create a DLL from this programme + wrapper and call this DLL from a modern GUI front end.

I have done this successfully before with more modern Fortran programmes by changing the main programme to a subroutine, and declaring the variables passed in and out that were originally read from or written to files and commenting out the write lines.  However, the Fortran programme in question is  around 8000 lines of very old Fortran with mostly implicit variables, so I would rather leave the code alone as much as possible, and just write a wrapper script to interface with this legacy code to handle the I/O to the code.  I am confident in compiling into a DLL and interfacing the DLL to the GUI via the wrapper script, it is the interface to the legacy programme to replace the I/O that I am stuck with.

Thanks

Richard

 

0 Kudos
10 Replies
Highlighted
Black Belt Retired Employee
49 Views

I don't understand why a wrapper is needed. Cards are just like files. As long as you open files on the desired unit numbers, it should work.

0 Kudos
Highlighted
Beginner
49 Views

Hello Steve,

Thanks for the quick reply. I want to remove files from the process, I would like to pass the required variables into the Fortran from the GUI and read the output variable back into the GUI. without having to make the GUI write input files/cards for the Fortran program to read, and then parsing the output files from the Fortran program to read the result back into the GUI. This way I can perform error checking on the inputs in the GUI and ensure they are passed as is to the Fortran without the user having a chance to "edit" the input files. I don't know if this is possible or not.

Thanks

Richard

0 Kudos
Highlighted
Valued Contributor III
49 Views

well we don't have much info to go on. How many variables would be passing from GUI to program, are they scalers, arrays, strings or mixed? It seems to me your GUI can have its own data structures and then in the program proper you replace all the read / write items with some functions to get and put data to/from the GUI. 

0 Kudos
Highlighted
Beginner
49 Views

Hello Andrew,

Thanks for the response, the simple answer is I don't know atm. I have the source code for the programme, but no example input or output files, so I can tell it is a mixture of scalars (float and ints) and arrays, at a guess 40-50 inputs. and a smilar number of outputs mostly arrays. 

 I have been asked to plug it into an existing front end GUI by extending that GUI to include the inputs and outputs, for this legacy program. The front end has data structures that can be used to pass the input data in the appropriate formats and receive the output data in the appropriate formats.

What I was hoping to avoid was making too many modifications to the legacy Fortran program, as it is a single file 8000 lines of code with very few explicity declared variables so if possible I wanted to leave it alone and just write an interface to it, rather than to go through and replace the read write functions with functions to pass/accept the variables.

However, if there isn't a better option that is the option I will have to take. I was hoping there would a generic method for replacing file I/O with the ability to pass variables directly, but it doesn't sound like there is.

Thanks

Richard

0 Kudos
Highlighted
Valued Contributor III
49 Views

If your program (for example) just asks for an input file and an output file why not just have your GUI write the input file and read the output file and have the GUI manage the files as temporary files? The change to the doing part of the code would then indeed be minimal.

0 Kudos
Highlighted
Black Belt
49 Views

I have exactly the same response as Andrew_4619. Write GUI versions of a virtual card reader, virtual card punch and virtual line printer, making each read or write a card-image file or line-image file, as appropriate. Connect the Fortran program to these files and let it run.

0 Kudos
Highlighted
Beginner
49 Views

Thanks for the replies.

So I take it there is no way of achieving this without reading and writing files? which is what I was hoping to avoid.

0 Kudos
Highlighted
Black Belt Retired Employee
49 Views

You could use CHARACTER(80) arrays, passed in from your driver program - just replace the unit number in the READ or WRITE with the array name. Each "card" will be one element of the array. I recommend using DIMENSION(:) for the arrays, requiring an explicit interface in the caller (assuming the driver program is also Fortran - if not there are alternatives.)

0 Kudos
Highlighted
New Contributor II
49 Views

Hello

Take a look here https://groups.google.com/forum/#!topic/comp.lang.python/VZcSln6gmKQ

It seems to contains a solution for a problem similar to yours.

0 Kudos
Highlighted
Beginner
49 Views

Hello Both,

Thanks very much for the replies,

I will look into the CHARACTER arrays that does sound like a good method for implementing the solution with minimal changes to the legacy code. I was planning on having a Fortran driver program then combining both into a DLL to call from the Python GUI.

The idea of using pipes sounds like exactly like the solution I was thinking about but didn't know how to describe. I will try and get my head round how to use this.

I could just make the GUI write input files for the Fortran program to read, then write a parser in the GUI to read the output files, but this just didn't seem to be a very elegant solution and the end users my colleagues have a nasty habit of editing  text input files, and not mentioning that fact when complaining the software doesn't work and is crashing. So I have learned the hard way to avoid having text input files where ever possible.

Thanks

Richard

 

0 Kudos