|
> This should be a quick one for most of you. What exactly is a service > program, or rather, how are they implemented? Is a service program like a > compiled, standalone subroutine or module of multiple subroutines? A *SRVPGM is just like a *PGM, except for two things: a) You can export subprocedures so that they can be called individually. b) You can't call a SRVPGM directly with the CALL command, it must be called from a *PGM object. Usually, yes, a service program is used as a library of subprocedures that can be called from programs. It's similar to a *MODULE (it's actually made of modules, like a *PGM is) except that when you bind modules together, copies of those modules are included in the *PGM. When you bind to a *SRVPGM, there's only one copy of the *SRVPGM that gets shared by all of the programs that use it. The nice thing about having one copy, instead of a separate copy for each program, is that when you want to make a change, you only have to re-create one object, rather than many. Saves a lot of time & headaches on the maintenance side. > I've read the comments people have made in reference to them but haven't > had a need for them so far. I think it's more likely that you do have a need for them, and you just don't know it yet. :) > I'm still getting my feet wet with procedures and procedure interfaces. > (I've used them for CALLP's and for replacing *ENTRY PLIST). This may > or may not be applicable but I am familiar with creating RPG modules and > then binding them into a executable program. You can't use procedures or procedure interfaces with CALLP or *ENTRY LIST. You're confusing procedures with prototypes. They're related, but they're not the same thing. Learning procedures is probably the best place to start, I think you're on the right track. Once you use subprocedures all the time, you'll find yourself saying "I wish I could put this subprocedure somewhere and call it from all of my programs!". And then the light goes on and you say "service programs are great!" And then you start saying "I'm tired of having to remember to use BNDSRVPGM() every time I compile this program." and then the light goes on about binding directories... > Specifically, I've been adapting some of Scott Klement's code for reading > and writing to the IFS in preparation for a project that's coming up. It's > been going good so far but one of the examples creates a service program > and uses it in later programs. I want to try to use it in my program but > I'm not sure if I understand the implementation. > The service program was successfully created in QGPL. > I'm using a /COPY member of Scott's to define the procedure. > I get the following error when I try to do a CRTBNDRPG on my program. Do I > need to create my program as a module and then bind it to the service > program? That would work. An alternative is to create a binding directory, and include that binding directory on the H-spec of the program you're calling it from. There's instructions for building a binding directory for the IFSTEXTR4 service program at the bottom of the following page: http://scottklement.com/rpg/ifs_ebook/textreading.html (The same instructions are in the .PDF copy of the document as well, but I don't know the page number off the top of my head) Once you've got a binding directory, you just need an H-spec like this: H DFTACTGRP(*NO) BNDDIR('MYLIB/MYBNDDIR') Plus, you have to copy the prototypes in with: /copy mylib/qrpglesrc,ifstext_h Those two lines of code are all it takes. You can now access all of the routines. Presto! :) > MY ERROR MESSAGE: > Message . . . . : Definition not found for symbol 'READLINE'. Library list is irrelevant... *SRVPGM's are either explcitly included with the BNDSRVPGM() parameter of the CRTPGM command, or by putting them in a binding directory and including it on the H-spec or on the CRTBNDRPG BNDDIR() parameter, or the CRTPGM BNDDIR() parameter. What a lot of people will do to make things even simpler is put *ALL* service programs in a single binding directory, and include that BNDDIR() in every program that they write. Then you never have to worry about it.
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.