× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



That comes down to shop standards. It shouldn't be in a "Library" unless
it is some sort of universal routine. Either it is a specific set of
code that is used in lots of programs and you are making it a service
program to facilitate code reuse, or it is code that follows the unix
philosophy of being a basic building block (
http://www.catb.org/esr/writings/taoup/html/ch01s06.html). If it's code
that doesn't meet one of those criteria, it needs to be a subprocedure
within the program that it is used by. Don't make service programs just
because you can, make them because they are useful.

I do however have the benefit of having been in the same shop for 15
years, and was the person who coordinated our move to ILE. We used the
Linoma toolbox to convert all our existing subroutines to subprocedures
and then individual programmers could propose candidates for inclusion
into a service program. We've ended up with 46 functions/procedures. 8
string routines, 4 date routines and 34 business logic routines that are
used in multiple places.





Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Booth
Martin
Sent: Thursday, July 21, 2016 10:49 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Is there a way to make %pbif's (Personal built in
functions)?


Fair comment Buck. First, my experience with sub-procedures is limited,
so there is confusion on my part. Bear that in mind as you try to
figure out what I am asking.

I have worked with sub-procedures in different shops. One problem
seemed universal. Each programmer had his own set of sub-procedures.
Was there overlap? Yes. But then, not really. Each sub-procedure was
just enough different that when it came time to use an existing
sub-procedure, it was almost just right, but not quite. After a few
years there is various libraries, various slants on the same problems,
and an overwhelming pile of sub-procedures to plow through to find one
that one could use in a current project.

So, I look at that mess and it seems to me that many shops lose the
benefits of sub-procedures after 5 years or so, especially if there is
turnover of programmers. It strikes me that this is very unlike most
things IBM i. Therefore I conclude there is something I do not
understand about implementing %PBiF's in a shop.
On 7/21/2016 5:28 PM, Buck Calabro wrote:
On 7/21/2016 4:05 PM, Booth Martin wrote:
Is there a way to make %pbif's (Personal built in function)? Maybe a

%%MyBIF()?

I suspect I know the answer. It seems like a natural addition but I

don't see how to do it.

As has been mentioned, write sub-procedures.
Depending exactly on what you're trying to build, you may want to
look into OPDESC support, although that isn't quite complete. I know

you're asking about a generic concept, but perhaps if you shared a
more concrete example we could suggest how to go about it.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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.