I have a similar issue every day. Our base application came from a S/36 and
the files all use the group prefix, such as A.SALES. When I externalize
these files, I create a compile version (SALES) in a separate library. That
library exists only in my library list. Files are accessed via either old
OCLs, CLs, or USROPN in the RPG IV program.
Jerry C. Adams
IBM i Programmer/Analyst
The profits shall be equally divided and the residue goes to the governor. -
Irish Bank Bill, 1808
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Victor Hunt
Sent: Thursday, April 05, 2012 2:14 PM
To: Midrange Systems Technical Discussion
Subject: Question on updating some OLD programs
I do apologize in advance for asking about something most folks dealt with
years and years ago...
I have a large number of programs in our sales reporting system that were
written a very long time ago. We are in the beginning stages of upgrading
them. In most cases, these programs have program defined files. In almost
all cases, the file name is something like SALES. There isn't a file on our
system called SALES. There are however files called SALES2012, SALES2011,
etc. The CL has an OVRDBF command to point SALES to the appropriate
SALESYYYY file for processing. Of course, this is variable as any SALESYYYY
file going back 10 years can be selected by the user.
As part of the upgrade, we'd like to change all program defined files to
externally defined files. Unfortunately, the file SALES doesn't exist so
compiles would fail. I could change them all to SALES2012, but at some point
this file won't exist either. I can create an empty file named SALES with
the same layout and no records, but this still has it's problems (there are
many programs where the file is defined more then once, SALES1 and SALES2,
for summary processing).
What is the best way to handle this situation? We are on 7.1 by the way if
it makes any difference in how we would handle this.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l