Interesting, but doesn't this create something of a logistical headache?
Whenever a change to the file is required, don't you have to make the same change to multiple (historical) versions of that same file?
How do new people receive this idea?
I'm of the opinion, one master file, not umpteen versions of a master file.


Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James Horn
Sent: Friday, April 06, 2012 10:09 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Question on updating some OLD programs

We create a programming library for this purpose which holds the "generic"
files to allow the program to compile. For ancient reasons we call it Q2Q. We would create file "sales" in Q2Q. To compile the program we would add Q2Q to the library list to compile it. When running the program use ovrdbf to use whatever file you want.

Jim

---------------------------------------------------------------------

message: 1
date: Thu, 5 Apr 2012 15:30:04 -0400
from: rob@xxxxxxxxx
subject: Re: Question on updating some OLD programs

Many people would have to either compile interactively, after manually typing in a few OVRDBF commands, or, write a 'make' program that compiles it after setting up the appropriate OVRDBF commands.

As long as your are modernizing you may want to consider abandoning the cl, if all it does is OVRDBF. I am not saying the presence of CL is bad but CL just for OVRDBF sake might be. It's not hard to add "user control"
to your Fspec and use QCMDEXC, system, QCAPCMD or your favorite to do the OVRDBF in the RPG program itself. Then OPEN the file. Doesn't alleviate your compile concerns but helps on the execution side.

The alternative, and I am also not saying it's 'best practices', I am simply saying it's an alternative, would be to eschew RPG file operations and use imbedded sql instead.


Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





--
Jim Horn
CATCO 651-697-6314 JDHorn@xxxxxxxxxxxxxx
Cell 612-791-3924
--
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.


Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].