Re: replacing binding by copy with binding by reference

On 2012/6/27 1:46 PM, Dave wrote:

As for changing to srvpgm, that's what I was worried about : all those
files that stay open, global and static variables,... It looks like
we'd have to go through every job to make sure that the difference in
behaviour of the new programs does not have any effect. Should we
start by eliminating the use of the dftactgrp while still using
binding by copy?

I don't think anyone has specifically mentioned this issue yet in this thread.

Say you have a module that uses a file defined on an F spec. When you have that module bound by copy in several programs, each module will have its own ODP for the file, no matter what is the activation group of the program. When you have that module in a service program, there will only be one ODP per activation group.

This can lead to inadvertent "file sharing", even if there is no SHARE(*YES) in effect for the file. That may or may not be a problem, depending on how the programs interact with the module that uses the file.

Here's an example of a problem scenario. Say the programs call a procedure in the file-module to write a record to a printer file, and then eventually close the file. In the one-module-per-program version, each program would get its own spool file. In the srvpgm version, there might only be one spool file with all the records from the various programs mixed together.

If each program runs in its own activation group, there would be no issue with the inadvertent file sharing. But there might be other worse issues caused by having each program in its own activation group. I think the most usual activation group strategies have all the programs in an application running in the same activation group, either explicitly or through *CALLER.

RPG's support for passing file parameters was added, in part, to address this problem, allowing the RPG program to pass the file as a parameter to the service program. That means the calling program "owns" the ODP rather than the service program, so the application can have as many ODPs for the file as it wants, even if all the programs run in the same activation group. But changing your application to use file parameters would be a pretty big task.

I don't want to give the impression that I'm warning you off using service programs. I think it's a great idea to use service programs rather than binding the same module by copy to more than one program. This is just to give an additional warning about the analysis you have to do, ideally in advance, but possibly when trying to figure out why something bizarre happened when you switched to put your module in a service program.