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




Loyd, 
there's a lot to learn, but it pays in the long run:

On Fri, 4 Dec 1998, lg - Loyd Goodbar wrote:

> So, could someone please verify the way I think this works.
> 
> 1. I write subprocedures and compile with PDM option 15 (CRTRPGMOD). I then
> have lots of module objects on the system. Do I keep these after creating a
> service program?

        It's up to you. You don't need them, but they might be handy in
case you have to recreate program or service program, and you don't want
to recompile all modules again. It's more matter of organization than
technical question. AND, let's not call them "subprocedures". Let's keep
that term for something else, other than just any member/module.

> 2. (I don't know the specifics) create a service program from all the modules
> (CRTSRVPGM?)

        That would be general approach. You should be more specific about
words "all the modules".
        

> 3. Insert /COPY members into my code for the procedure calling interface
> (P specs) 

        Not exactly. You may want to use /COPY for prototypes (PR type of
D-specs). Your P-specs are supposed to be in service program(s) or
imported from other modules within same (main) program. It is possible to
put subprocedures (P-specs) in "/COPY" members, but it would be wery
outdated, inconvinient (my oppinion) and in that case you don't need
service program. For the begining, I suggest, you stay away from
subprocedures until you have clear idea about whole ILE concept. 

> 
> Is there an advantage of having one large service program versus service
> programs segmented by function? What steps are necessary when a service
> program module needs updating?
> 

        No, not at all. The best tactics is to group modules in service
programs based on probability for most of them to be called in the same
run of main program (e.g., program using service program). Reason for that
is in concept of activation. When main program is called, it will activate
whole service program which is bounded to it, regardles of actual modules
which are going to be called. It will result in allocation of certain
resources (static memory ...) and it won't be brought bact to the system
until activation group is reclaimed. So, if not used, it's vaste. It would
be like taking loan from bank, and then keeping money in a safety deposit
box. 

        If you want to update some module in service program, there are
two ways to do it. Recreate service program or update service program
(UPDSRVPGM). In both cases, you will have to take care about something
called "signature". Basicaly, you must not change srvpgm's interface
(procedure names, number and types of input parameters ...) unless you
want to recreate all programs using that service program. There is also
"binder language" to help you out with it, but let's stay away from it
(for now). Use EXPORT(*ALL) parameter in CRTSRVPGM.


> How does this change how I create my RPG/IV programs? For compatibility, I
> have compiled using option 14 (CRTBNDRPG). Do I have to abandon this setup and
> create program modules instead? 

        Yes and no again, depending of your concept. Yo can still use
CRTBNDRPG if you use binding directory to help your program find
appropriate service program (last time I checked, CRTBNDRPG let you set
binding directory, but not SRVPGM; it  might be changed in some releases
of OS). You'll notice one other diference. With srvpgms naturally goes
static call (CALLB, CALLP). You'll have to set DFTACTGRP(*NO) in
CRTBNDRPG, and then ACTGRP(*CALLER) or ACTGRP(<whatever name you like>)
or simply accept default QILE (don't be afraid of "Q", it's just a name)

        Other way (which is more natural for real ILE application) is to
create module(s) (option 15; don't forget that your "main" program doesn't
necessarily have to have only one module, it doesn't even have to be
written in only one programming language), then CRTPGM, and put your
SRVPGM as a corresponding parm. 

> How do I interact with the service program? Do
> I need to worry about activation groups when I use the service program? 
> 

        Yes, very much. Not only when you use srvpgms, but in whole ILE.
First thing that you're gonna notice is that your "overides" and
"opnqryfiles" don't behave exactly as you may expect. You'll need good
understanding of activation groups, hard and soft control boundaries ...,
especially if you use some other languages (ILE COBOL, ILE CL, ILE C;:)))
never say never, more you eat, more enjoyable your meal becomes). Back to
srvpgms, always use ACTGRP(*CALLER) in CRTSRVPGM command (unless you have
a good reason to run it in separate AG)


> I know I should get a book. Which RPG/IV books have decent information
> regarding procedures and prototyping, and the other "fun" ILE stuff?


        Yes, and not only one. You'll also need a lot of time and will to
experiment and play around with all this stuff. Good books are IBM
manuals:  ILE Example V3.7 (or higher), ILE RPG Reference, ILE RPG
Programmers Guide. 

Good luck

Vanya Jovic
(who is looking into -30C very soon in Canada)

P.S. I can see you are very anxious about subprocedures and prototypes. As
great as they are, they are not so essential in ILE RPG (except for
sockets and similar areas), so I suggest get a big picture first.



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


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.