|
On Thu, 2004-07-22 at 18:51, daparnin@xxxxxxxxxxxxxxxxxx wrote: > > This should be a quick one for most of you. Ha! > What exactly is a service > program, or rather, how are they implemented? The short explanation is that a service program is a collection of *MODULE objects (1 or more). Those *MODULE objects contain procedures, some (or all) are "exported", meaning that they are available to be called from outside the service program, say from your main program or another service program. (The corollary is that procedures in the service program that are NOT exported cannot be accessed outside of their *MODULE). A *MODULE can have one-or-many of these procedures. Once a service program is created, it is implemented by "binding" it to a program. This is done either by specifying the service program to be bound on the CRTPGM command or by putting the service program in a binding directory and referencing the binding directory on the CRTPGM command. This can also be accomplished by using an "H-Spec" in the *MODULE's source code. > Is a service program like a > compiled, standalone subroutine or module of multiple subroutines? Basically, yes, accept a service program cannot be called. The exported procedures of a service program can be called (using callp) from programs and other service programs (if they are bound as discussed above), but the service program itself cannot be called directly. This makes sense once you realize that a service program has no *ENTRY point. > I've > read the comments people have made in reference to them but haven't had a > need for them so far. 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. OK, creating a service program is simply binding *MODULEs together into a special kind of a program. Procedure rles are the same: you need a prototype and an interface in order to be able to call a procedure in a service program. These are typically extrnalized by putting them into /copy members. > 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? At CRTxxx time, your program cannot find the procedure 'READLINE', which I assume is in your service program. Look at the first paragraph of my response above: you need to reference the service program one way or the other in order to use one of its procedures. Otherwise, the compiler cannot find the reference to the procedure, which is what it is reporting below. > > MY ERROR MESSAGE: > Message . . . . : Definition not found for symbol 'READLINE'. > Cause . . . . . : No definition was found for reference READLINE in > *MODULE > object NISCOTST1 in library QTEMP. The definition either does not exist > or > is not of the same data or procedure type as the reference. Recovery . . > . > : Try the Create Program (CRTPGM) command again, supplying an object > that > contains a definition for symbol READLINE. // stuff cut... > Any help or advice would be appreciated. If I may suggest, I have a series of ILE articles that I think would help you a lot. They deal specifically with the kinds of questions you are asking. Start at the top and read the first 5 or 6 in order. You can find them listed here: http://www.rpgnext.com/tutorials.php Best of Luck, Joel Cochran http://www.rpgnext.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.