I guess it could be a logistics nightmare, but it seemed to be one of those
things that came about over years. The primary reason because, in the past,
there was not sufficient disk space to hold all of the data. Later, when
disk space existed, it was easier just to retain the multiple library
structure and build a logical over all of them.
I had sales history in multiple libraries and had to add or change fields on
several occasions. It was easy to write the conversion program and just
pass it over each version.
But that was a one-man shop and a not very complex system.
Here we have a sales history going back to 1999. I have toyed with the idea
of actually splitting it off into two tables: one for the current year+last
year and another one for everything else. Reason? Because queries, which
is the most common usage over these tables, run real slow now. (Of course,
we are on an old Model 250 running V5R1 so what could we expect?!)
Jerry C. Adams
IBM i Programmer/Analyst
Anyone can be elected governor. I'm proof of that. - Joe Frank Harris,
Georgia governor
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Friday, April 06, 2012 9:15 AM
To: Midrange Systems Technical Discussion
Subject: RE: Question on updating some OLD programs
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 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
