×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
As an Amazon Associate we earn from qualifying purchases.