Hi.
I have come across where I work, over and over the same situation:
You have a program accessing many files (from a specific year, for example) and I can use the same program using files from another year. Is there a way I can avoid making a copy of the program just because I want to use another set of files? The problem is maintenance when you have to alter one, you have to alter them all… 
Example: Program1 View1, Program 2 (which is an exact copy of Program 1) and View2 (different than View1)
I have thought of using global views but it doesn’t help since I have to declare them on the programs also (subroutine for example)…
Note: They DBAs don’t like using a multi-year files…
Thanks in advance,
Jackie
If only the date of the data is different, that means that the lists of fields in the DDMs are the same, correct? Only the file name and file number in the DDM header change from year to year. In that case you have two options.
- Look at the Dynamic Source Text Creation/Execution section of the RUN statement in the Statements manual. You can supply the file/DDM name dynamically, then generate and run the source code.
- Use the TF parameter. Let’s say your program was STOWed with file number 123 for 2017 data and you want to access file 124 for 2018 data. In your JCL you specify TF=(,123,,124) and execute your program normally. You may need to adjust the TF specifications to suit your needs. If you execute the program on-line, the TF parameter is not available, but you can execute user exit USR2005N to accomplish the same thing.
Hi, Ralph.
Thanks for your help. First I tried option number 2. Unfortunately it only worked with some fields. I got NAT3055 and I found out why=> the DB Short names don’t always correspond from one year to the next…
Option number 1 works fine but I have to run the first program in order to be able to compile the program being called, otherwise a get a NAT0890 Invalid source parameter construction. The programs are going into production…
Any ideas???
Yes, but probably not practical. The idiot(s) who used different DB names for fields which exist across multiple files should be given the task of fixing the mess they created.
How many years of data are you talking about? How many such scenarios exist?
While I understand why most shops do not permit RUNning programs in production, I have never understood why RUN has been banned when the alternatives (as in the problem you have identified) can be VERY messy.
One idea that I can imagine is to externalize the data access from the program. Create a subprogram that reads the data from the files and returns it to the program that processes the data. The data access subprogram would either have a file view for every year and retrieve the data from the correct file, or it could be a gatekeeper for separate modules that retrieve data from a single year and the gatekeeper calls the correct module based on the year requested.
Each year you would need to update the retrieval subprogram(s) to add the new year’s file(s), but the main program can stay the same.
Another alternative, if this process is running in batch is to have a separate program that reads the data from the file and writes it to a workfile then read the workfile and process the data. Then your main program only needs to know how to read the workfile, not how to read each year’s file.
Thank you all for your help and suggestions!
I ended up using copycode for the main program. I wanted a more sofisticated solution but found too many obstacles…
I reduced my scenario when I described the problem in this thread, in order to simplify things. I have 8 files per year (for this program only - there are more than 20 files total!).
I have a program like this now:
DEFINE DATA
LOCAL USING ==> This doesn’t change
LOCAL USING ==> This changes every year
END-DEFINE
**
INCLUDE ==> If there is a change, that’s the only place to make changes and it will work for every year.
**
END
Every year I’ll have to change the views and create a new program copied from with the same