I, too, keep a separate /copybook for each prototype external to the
program. But, even if the PR's are all in one /copybook, the program only
cares about those that it needs/uses. I used a package at my last place of
employment that kept all prototypes in a single /copybook; that way all I
had to do was code a single /copy statement; when I wanted to use a
function, it was available.
For a simple example, let's say that the copybook (Functions) included
prototypes for FunctionA, FunctionB, and FunctionC. All I have to code in
the D-specs is D/copy Functions. If I only use FunctionC in Calcs, the
other copied prototypes are superfluous but not a problem (except that they
are included in the compilation listing, which is a clutter).
I have often considered creating nested copybooks with similar functions in
each. Just never got around to it.
Jerry C. Adams
IBM i Programmer/Analyst
There will be a procession next Sunday afternoon in the grounds of the
Monastery; but if it rains in the afternoon, the procession will take place
in the morning. - Announcement read to a church congregation
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Kurt Anderson
Sent: Thursday, June 30, 2011 9:11 AM
To: RPG programming on the IBM i / System i
Subject: Copybooking PRs WasRE: Impossible to even think about rewriting in
RPG
In this list and in presentations I often hear about people putting _all_ of
their prototypes into _one_ copybook. This has always boggled my mind and I
feel like maybe there's something I'm not grasping.
Like Bryce, we have a special source member for copybooks (we make these
members end in a Y - C was taken for CLs). Each Service Program of ours has
its own copybook to share its exported procedure prototypes as well as any
Data Structure templates, global variables or constants required by the
caller or service program.
I can't imagine putting all of that into one copybook. It seems like a step
toward the monolithic pain in the a$$. I'd imagine cleanup of it would be a
pain as well.
Thoughts?
Kurt Anderson
Sr. Programmer/Analyst
CustomCall Data Systems
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Bryce Martin
Sent: Thursday, June 30, 2011 8:04 AM
To: RPG programming on the IBM i / System i
Subject: Re: Impossible to even think about rewriting in RPG
John,
I know it seems a bit scattered, but I put all of my PR's in source members
in a source file called QCOPYSRC. So anytime I need a prototype for a
service program or regular program I just do...
/copy QCOPYSRC,PROGCP
So instead of suffixing with an R or P or whatever you use in the program
name I'll suffix my copy members with CP. So there isn't really much to
think about. That will then make those available to call. Once the
organization is set up and you get your thinking to line up with the new
methods and processes it becomes second nature and, in my experience, is
much faster and more organized.
Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
John Yeung <gallium.arsenide@xxxxxxxxx> Sent by:
rpg400-l-bounces@xxxxxxxxxxxx
06/29/2011 10:11 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
"RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
cc
Subject
Re: Impossible to even think about rewriting in RPG
Barbara,
I appreciate your patience and professionalism. Despite my
blathering, you still make a genuine, nonjudgmental effort to reach
out. I'll look into it more when I get a chance. I've always gotten
an icky feeling with /copy, but I suppose it's no worse than
#include-ing C header files. (Not that I'm too happy with #include.)
It's yet another place where the program is scattered about, another
piece to maintain. We'll see how it goes.
John
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.