I have 10 files and I am making a report out of these files, I have 10 record formats in my printer file each corresponds to each file. I have used 10 subroutine for each files and writing to report independently. My program is working well but I need a clarification, is this a fair approach?

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your response...

Discuss This Question: 10 &nbspReplies

There was an error processing your information. Please try again later.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

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

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.

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.

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

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

Share this item with your network:

To follow this tag...

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy