× 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.


  1.  Home
  2. RPG400-L
  3. October 2009

Re: Service programs and QSRVSRC

We always goes by one *SRVPGM/*PGM always created from one *MODULE. No *SRVPGM/*PGM is created from 2 or more *MODULE. I still could quite understand what you mean by "protected is applied to a *SRVPGM procedure". If you exported a procedure in a *SRVPGM, that procedure will be visible to all other *PGM/*SRVPGM/*MODULE.




"Charles Wilt" <charles.wilt@xxxxxxxxx> wrote in message news:<mailman.6801.1255635983.1811.rpg400-l@xxxxxxxxxxxx>...
Lim,

protected is applied to a *SRVPGM procedure, not a *PGM one.

Do you create *SRVPGMs from multiple modules?

Rather than having everything for a *SRVPGM in a single source member
and thus a single module, I may have something like so:
INVENTORY *SRVPGM made up of all INVxxxx modules
INVENTORY *MODULE, public procedures (interface) to the service prgram
INVMASTER *MODULE, protected procedures that write to the Inventory
Master file(s)
INVHIST *MODULE, protected procedures that write to the Inventory
History file(s)
ect...

All of the INV* modules are only ever bound into the INVENTORY *SRVPGM.

Another example, consider the thread "procedure to set global
variable"; one of the suggestions was to encapsulate the variable in
it's own module with get/set procs. That kind of encapsulation fits
quite nicely into the idea of a multiple module *SRVPGM with public,
protected, and private procedures.

HTH,
Charles



On Thu, Oct 15, 2009 at 2:35 PM, Lim Hock-Chai
<Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote:
Hhmm, doesn't the protected export you mentioned will only applied to *module to *module binding?  If so, I think we are talking about the samething.  As mentioned, at our shop, a program is always created from a module.  We don't create a program using 2 or more *MODULE.  Don't never see the need to break a program into multiple *module.



"Charles Wilt" <charles.wilt@xxxxxxxxx> wrote in message news:<mailman.6761.1255631084.1811.rpg400-l@xxxxxxxxxxxx>...
Lim,

The idea of protected procedures has nothing to do with "bind by
copy"....or at least nothing to do with having modules bound into a
program with bind by copy; since technically if you have service
programs made up of multiple modules then you have bound those modules
by copy into the service program.

I like be able to break up the code into multiple source members.  But
the resulting modules are only used in a single *SRVPGM.

Charles

On Thu, Oct 15, 2009 at 2:08 PM, Lim Hock-Chai
<Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote:
Our shop does not use bind-by-copy.  So... Protected level doesn't quite
apply to our shop.  But I can see that would be useful for others.

I don't ever think of a situation where I would want to create a program
using multiple *MODULE.  If there are common functions that needed by
other programs, I put those functions in a service program and bind them
with the service program.




"Charles Wilt" <charles.wilt@xxxxxxxxx> wrote in message
news:<mailman.6401.1255463858.1811.rpg400-l@xxxxxxxxxxxx>...
I'd recommend always using binder language, never export *ALL.

By using binder language, your procedures can have 3 levels of
visibility
1) Public (exported and in binder source)
2) Protected, only usable by other procedures in the service program
(exported but NOT in binder source)
3) Private, only usable by other procedures in the same module (not
exported)

Without binder source, your only options are public or private.

I'd say your option 2 should be
2) Use binder source with only a PGMLVL(*CURRENT).  You'll need to
rebind anything using teh service program if you add exports.

-Charles
--
This is the RPG programming on the IBM i / System i (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.


----------
--
This is the RPG programming on the IBM i / System i (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.


----------

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
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.