ILE binding - *modules vs. *SRVPGMs

[jayvaughn]

when developing external bound procedures - what are pros and cons of each.

1.) simply creating a *MODULE and a PR copybook and binding via a binding directory
or
2.) finishing off #1 with a binder language source member and creating a *SRVPGM from it

What you would end up with is a binding directory that references either the *MODULE (#1) or the *SRVPGM (#2) for your program to bind to for those procedures.

I have always felt like #2 (*SRVPGM's) are a bit overkill and tend to never do #2 above.

I know *SRVPGM's are popular, but any issues with leaving it at the *MODULE level?

[TedHolt]

If you bind to a module, then you have to rebind to the callers when you change the module in order for the callers to get the updated module.

If you bind to a service program, the calling routines do not have to rebind when you change the service program.

[jayvaughn]

i'd say that is definitely an advantage and probably bout the only advantage - if you utilize a change management system such as Turnover or Aldon, I just suppose it is more work for it to do if you don't go the entire *SRVPGM route, and therefor not really an advantage to the developer's perspective.

[tomliotta]

Maybe start with a different question: Why are you creating an external *MODULE object?

As you noted, a decent CMS could conceivably track and recreate everything (as long as nothing is ever done outside the CMS). But *SRVPGMs can have useful "signatures" that developers and the system both can take advantage of. Making use of them can let you go far beyond what simple *MODULEs allow.

[Barbara Morris]

Depending on how many programs your module gets bound to, using modules can make your application much bigger than it would be if you used service programs. It's a similar footprint increase that you'd get if you had a SUBPGM *PGM called by PGM1, PGM2 and PGM3, and instead of having one SUBPGM, you had duplicate SUBPGM1, SUBPGM2, SUBPGM3 to be called by PGM1, PGM2 and PGM3.

[Scott Klement]

Let me ask you this: Would you ever consider eliminating having multiple *PGM objects? Just have one big *PGM that does everything your application needs to do, without ever needing another *PGM anywhere. You could split the code into multiple members with /COPY. Would that be a good solution for you? Why or why not?

Because, that's very similar to binding the module to each program that needs it. Binding the module makes a copy of your code and inserts it into the program.

Granted, there are differences... I get that. But, this is the concept.

A *SRVPGM is almost exactly like a *PGM. The only difference is that in a *SRVPGM you call the subprocedures directly, whereas a *PGM always calls the main procedure. That's it -- they're otherwise identicial. If you can see the advantages of having multiple *PGM objects, you should also be able to see the advantages of *SRVPGM objects.

[JonBoy]

If you bind to a module, then you have to rebind to the callers when you change the module in order for the callers to get the updated module.

If you bind to a service program, the calling routines do not have to rebind when you change the service program.

<< Deleted - just seen Barbara's comment which was basically the same thing >>

[jayvaughn]

Let me ask you this: Would you ever consider eliminating having multiple *PGM objects? Just have one big *PGM that does everything your application needs to do, without ever needing another *PGM anywhere. You could split the code into multiple members with /COPY. Would that be a good solution for you? Why or why not?

Because, that's very similar to binding the module to each program that needs it. Binding the module makes a copy of your code and inserts it into the program.

Granted, there are differences... I get that. But, this is the concept.

A *SRVPGM is almost exactly like a *PGM. The only difference is that in a *SRVPGM you call the subprocedures directly, whereas a *PGM always calls the main procedure. That's it -- they're otherwise identicial. If you can see the advantages of having multiple *PGM objects, you should also be able to see the advantages of *SRVPGM objects.

if you read my original post, i'm pretty sure i have a good understanding of *modules vs. *srvpgms - i'm curious as to what the advantages of going the extra step to create the *srvpgm really are.
I've yet to be convinced it is the best practice.
By comparing my method to a huge monolithic pgm by using /copy (that have no PI's and parm checking at compile time), tells me you are not understanding my inquiry.

My *module has NOMAIN and consists of nothing but short exportable procedures. When my pgm binds to it, it only binds (copy's) the exportable procedures referenced into it and creates the *pgm. No?

Look, i get creating *srvpgms for utility type procedures that can be global to many pgms and contain no biz logic (as they may really get around and be dependent upon by MANY different pgms)... but personally, i like to use just a *module to bind to biz process related *pgms. Just a preference. I totally understand I can carry that forward with more effort and create yet another object (*srvpgm object), oh and also create a binder language source member to also maintain... but my preference is to not do that.

So far Barbara's reply about recompiling all dependents is the biggest pro of the *SRVPGM (and i knew this coming in), but didn't want to lead anyone in that direction alone. But as I've said, my *module is isolated to biz logic procedures that only bind to a distinct smaller group of pgms. But also didn't want to distract anyone with that in my original inquiry either.

So we are left with the recompiling advantage, which really is not a big issue when using a CSM.
Anything else that may be a pro to a *srvpgm?

[Barbara Morris]

Jay, are you planning to avoid service programs entirely, or just for cases where a module would be bound to a small number of programs? If you plan on avoiding them entirely, because you currently only see a need for sharing modules across a few programs, this practice could prevent you from taking advantage of service programs for cases where they are, or might later be, needed by many many programs.

If you rebuild everything whenever a change is made, then what I'm going to say now wouldn't be a factor. But if you only rebuild things that need to be rebuilt, then you could get into an icky state where programs are bound to various different versions of a module. Say you add procedure someproc() needed by program P1. You recreate the module, and rebuild program P1. Programs P2 and P3 still have the old module. Now you add someOtherProc needed by program P3 and rebuild P3. Now P1 has version2, P2 has version1, and P3 has version3. *shudder*

[jayvaughn]

Well put Barbara. I can see where a "single point of contact" could be beneficial in that respect. Perhaps i reconsider always taking the extra effort in building g that single point of contact.

[TedHolt]

i get creating *srvpgms for utility type procedures that can be global to many pgms and contain no biz logic (as they may really get around and be dependent upon by MANY different pgms)... but personally, i like to use just a *module to bind to biz process related *pgms.

As wonderful as it is to use service programs for utility functions, I think there's an even greater case for putting business processes in service programs. When the business changes the way it operates, I change the appropriate routine(s) in the service programs.