The concept of service programs is one of the most valuable additions of all time to the RPG application development toolset on the System i. The ability to externalize and group specific and well-defined program functions into service programs makes it so much easier to support function reusability as well as focus on the core program logic and functionality in your programs. Perhaps even more than a practical achievement, service programs offer a welcome twist to a programmer’s mindset, in terms of the design and development approach promoted and encouraged when taking advantage of service programs in your daily programming efforts.
Organizing and maintaining service programs, however, requires care and thought. The system supports and enforces integrity between service programs and the programs or service programs to which they’re bound. Because the binding to a service program and its exported subprocedures or data is established at the point where a referencing program or service program is created, the system attempts to verify at program activation time that the service program has not changed in an incompatible way since the initial binding. Sometimes the ability to resolve service programs’ references and verify maintained integrity ahead of time therefore comes in handy. And so do APIs.
To ensure integrity between a service program and the programs or service programs referencing it, all service programs are tagged with a current signature. This signature identifies the number and sequence of the exported procedures and data from the service program and is defined whenever the service program is created. You have the option of letting the system generate the signature by specifying the keyword EXPORT(*ALL) on the Create Service Program (CRTSRVPGM) command. This will cause the compiler to generate a signature based on the number, names, and order of the service program’s subprocedures being defined with the EXPORT keyword on their procedure interface specifications.
Articles on Apis 