Re: replacing binding by copy with binding by reference

Wow, that's cooled me off a little, I must say!

So, if I was using a single module to control all i/o on a database
file, I might position the file, read a record with an external call
to this module, then return, then go back expecting a next record but
another program could have changed the file position in that time? The
sharing only occurs between program in the same job though. What else
get's shared?
It would seem to me that programs would have to gradually evolve to
using that kind of binding, ie whenever possible during maintenance
change the *module declaration in the binding directory to *srvpgm. It
also seems to me to be urgent to stop the creation of new programs
bound by copy as at that stage, I would imagin implementing service
programs would be easier.

2012/6/28 Barbara Morris <bmorris@xxxxxxxxxx>:

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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.