Advantages of using Binding Directories over Service Program in AS/400?

425 pts.
Tags:
AS/400 Binding Directory
AS/400 service program
Can someone tell me the major advantages of using Binding Directories over Service Program?

Software/Hardware used:
Iseries
ASKED: February 16, 2010  4:21 PM
UPDATED: March 1, 2010  12:49 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.

You can use the BNDDIR keyword in the Header specification section of your program and use the CRTBNDRPG command to compile. Otherwise, you are required to use a two-step compile in order to bind the service program to your program object.

==========================================================

The question implies that one or the other is to be used, and that isn’t quite correct. If you use binding directories, you should probably still use service programs.

The question might be better as “When I use service programs and modules, should I use binding directories to locate them?”

A binding directory is little more than a list of objects. The objects are identified by their names, libraries and types. The types can be *SRVPGM and *MODULE. (That’s the basic level. More detail can be used.)

For basic usage, that’s about all there is to it. Add entries to a binding directory with the ADDBNDDIRE (Add Binding Directory Entry) command. Then when you create a program, you don’t list the modules and service programs on the CRTPGM command. Instead, you just name the binding directory. The compiler will find the names in the directory and then be able to grab the objects.

You might create a personal binding directory for yourself. You’d add entries to it that named objects in your own development libraries instead of production libraries. Those might all have full debug included or might even have calls to special logging modules that aren’t used in production. When you create a program with your binding directory, it could have all the extra added stuff that you need for testing. You could list every module and service program in one binding directory — if your program only uses one or a few of the objects, it doesn’t matter.

When you wanted a production version of the program, you would replace the name of your binding directory with one that referenced objects with all debug removed and with no extra calls to developer routines. That would create a version of the program that only referenced production-level service programs and modules.

Essentially, just by changing the CRTPGM BNDDIR() parameter, you would create a very different version of the program.

Using a binding directory also allows you to hide some of your service program exports.

You might have a *SRVPGM with three modules — ModA, ModB and ModC. ModC has an exported procedure — ProcC — that is intended only for the use of other modules in the same *SRVPGM and not for public users of the *SRVPGM. ProcC must be set to EXPORT in order for procs in ModA and ModB to see it. But you need a way to limit the export just inside the *SRVPGM itself.

You do that be leaving ProcC off of the list of EXPORTs in the STRPGMEXP entry in the binding directory. The binding directory entry is then what you make available as the public interface to your service program.

You can create one binding directory for your system. You can create a binding directory for each application. You can create multiple binding directories for each application, if different directories serve different purposes. You can even create a binding directory for each program just so you don’t have to remember which modules and service programs to include the next time you compile it. (Maybe even name the binding directory the same as the program.)

Nobody can really tell you what the advantages are. The advantages are always only those characteristics that you use. Next time you create a program that references a bunch of modules and/or service programs, simply create the directory, populate it with entries and see how it affects program creation. It will either work well for you or it won’t.

Tom

Discuss This Question: 1  Reply

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • NullFields
    At our shop, we like using Service Programs over Binding Directories for these reasons: When compiling a program with binding directories, the required modules found in the binding directory become part of the compiled program. So every program that uses a module linked via a binding directory has its own copy of that module. With a compile of a program that links modules via a service program, the module is just referenced at compile time and executed from the service program at run time. This makes it so you only have one copy of the module being executed. So, if you have a code change that does not modify the interface between the calling prorgam and module, with a binding directory reference during compile, you will still have to recompile the changing module and all the programs that bind in this module. With a service program, you will need only recompile the changing module and the service program for all the users to take advantage of the new code. We have a fuzzy rule we try to follow. Compile the module and bind it to a program only once (either a *SRVPGM where it can be reused, or a *PGM where it won't be reusable) A nice mix that seems to fit a majority of our needs is binding *MODULEs to a *SRVPGM and then put the *SRVPGM into one or more *BNDDIRs. PSM
    880 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following