|
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 mailing list archive is Copyright 1997-2025 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.