Since we can’t see your programming, we don’t know if it is coded appropriately or not. We don’t know your OS version nor what languages you are programming in. We don’t know if you’re using native I/O or SQL. We don’t know your report structure. We don’t know the business logic that relates the files to each other. I don’t see a way to guess if you’re using a fair approach or not. — Tom

If the fields with the same name have the same structure then this will work. 
If they don’t have the same structure the program won’t compile.
 

I assume the record formats are a different layout but keep the same fields and field definitions. If you are processing just 1 file at a time it should work fine? If the record formats are the same I would see if making it either a parameter driven applications based on the individual file or in the code use a call QCMDEXC to do an OVRDBF to access the other files and still have all the data on one report.

Do all 10 files need to be open at the same time?

It’s not possible to say if it’s a “fair approach” or not. We don’t have the code to see if alternatives will work.
 
We don’t know the OS version. We don’t know what language you’re coding in. If it’s RPG, we don’t know OPM or ILE.
 
If the files are processed separately, we don’t know why you would need to rename any of the fields. Under many logic circumstances, it’s not needed, nor is prefixing or qualification. Specifying data structures isn’t even needed.
 
But we don’t know anything about the files. We don’t know if relationships exist or the business logic that brings them together.
 
We don’t know what the report’s business purpose is nor its structure.
 
Renaming is useful because it takes no extra CPU cycles in your C-specs. By using appropriate naming techniques in D-specs, you can often simplify a lot of C-specs. But it’s only needed when values from multiple fields with the same names in different files are needed simultaneously, and then only if you don’t specify separate data structures. If files are processed separately without separate data structures, there’s no need for renaming in RPG. It can, however, be useful if logic is complex and maintenance will be easier if the values are individually identified.
 
As it is, we don’t even know if any C-specs are needed at all. It’s possible that this program could be a very straightforward ‘Cycle’ program with no I-, C- or O-specs (except possible references to external database and printer files).
 
So, it might be a “fair approach”. Or it might be unnecessary. No way to know from the question.
 
Tom

All 10 files open at the same time. I have put 10 ‘ExSR subroutine’ one after the other.  And each subroutine is meant for each file and in each of these subroutine I am writing each printer file record format. From the discussion I conclude the last file read will override the previous value in the field and so there wont be any issue.

From the discussion I conclude the last file read will override the previous value in the field and so there wont be any issue.
 
If the program structure and code is correct, then your conclusion will be correct. But if you code differently, then your conclusion can be wrong. The use of subroutines has bearing on this at all, so there’s no reason to mention that to use. Things will work exactly the same if you put the code in-line.
 
But numerous other coding elements could make your conclusion wrong.

IBM provides an easy technique to make field names unique when the same name is used in multiple files in a single program.  Check out the F-spec keywork “PREFIX”. 

It will work. But Field values will be taken from last read File. It may create confusion
 
Any programming element will be confusing to someone not familiar with that element.
 
A MOVE statement in COBOL can be confusing to someone who expects the value to be moved rather than copied. Trigraphs in C can be confusing to… well, almost anyone who isn’t using them regularly. List parameters in CL commands are confusing to CL programmers who first try to assign variables to them.
 
Tom