If you are on release 6.1 or higher, you do not need any CL:
1. Create a dummy file named SALES (based on the DDS description or even as
SQL Table)
2. Specify the SALES table in composition with keyword EXTDESC(SALES)
ExtDesc will only be used at compile time to find the file/field
description to be included in the module/program
3. Use the keyword EXTFILE(MyVar) in composition with an variable in the
F-Specs.
4. Define the file as user controlled open.
5. In your program move the file name with the appropriate year into your
variable (MYVAR) and open the file:
F SALES IF E Disk ExtDesc(SALES)
UsrOpn
F
ExtName(MyVar)
/Free
If %Open(Sales);
Close Sales;
EndIf;
MyVar = 'SALES' + MyYearChar;
Open Sales;
....
Use dynamic SQL to access whatever table/file/view you want.
Static SQL is not possible, because setting tables/files and views with host
variables is NOT allowed.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Booth Martin
Gesendet: Friday, 06.4 2012 04:26
An: Midrange Systems Technical Discussion
Betreff: Re: Question on updating some OLD programs
It isn't just clear to me how this is used, but this scenario might be
desirable for you?
1) Create the external file description (empty) for SALES.
2) Do not use CL.
3) Change the F-specs to FSALES... usropn
4) In the *inzsr, write a small loop that displays a screen asking for the
fiscal year (or special suffix).
5) Once a valid suffix is chosen, do a OVRDBF and then open the user's
chosen file.
6) It wouldn't take much to have a new small program that can be called in
the *inzsr that has a window with a dropdown box of available years (and
other, special, suffixes) that can be chosen. That would probably be used
repeatedly by all of the various programs.
On 4/5/2012 2:13 PM, Victor Hunt wrote:
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.
--
Booth Martin
802-461-5349
http://www.martinvt.com
--
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,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
