On 28-May-2014 08:38 -0500, Sadler, Pete wrote:
I am having problems with files being left open in the DDM server
job QRWTSRVR.
Here's the setup...
SystemA has a database file called REQUEST
SystemB has a corresponding DDM file called REQUESTDDM pointing at
the file on SystemA
The sequence of events...
* A program on SystemB needs to update some database files on
SystemA. These files are country-specific, i.e. each country has its
own set of data libraries.
* The program on SystemB writes a record to the REQUESTDDM file
containing details of what program should be called on SystemA,
along with the required country.
* A trigger program attached to the REQUEST file on SystemA is
activated and reads the request record.
* The trigger program sets up the library list according to the
requested country.
* The trigger program then calls the appropriate program as
specified in the request.
* Trigger program then terminates with *INLR on.
The Distributed Data Management (DDM) is meant to allow your
application to run on SystemB using DDM Files (DDMF) to redirect the
requests made to the DDM file on SystemB to perform that requested
action on the corresponding\target file on SystemA. As Charles notes,
the above described scenario is little different than messaging to
perform the work on the target system, and thus, DDM Data Queues are
just as if not even more appropriate.
The problem...
A large number of the programs called on SystemA are OPM programs and
return with *INLR off, hence leaving files open. When the next
request is made, the trigger program sets up the library list for the
new country and calls the appropriate program(s). Although the
library list is correct for the new country, many files are still
left open from the previous request and hence for the wrong country.
This could be disastrous when the requested program performs file
updates!
To me, the obvious solution is to make the initialization phase for
the "new country" to ask the application to close all of the files from
the last invocation [if the "new country" is not equal to the "previous
country" that was being processed; similarly, the LIBL should not be
changed if "new"="prv" because the environment has not changed].
However I personally disagree with using a trigger program to do any
type of initialization like that; I find such actions somewhat
disturbing, and not just for performance implications. I like the
logical separation that is enabled via a response to a data queue
message or a response to a specific DDM request message [i.e. Submit
Remote Command (SBMRMTCMD)]. For example, rather than using the I/O to
the REQUESTDDM, that DDMF could be specified on the SBMRMTCMD to ask the
DDM Server to perform a specific request. As others have suggested,
that request could be a Submit Job (SBMJOB) command request that
[possibly after establishing the library list, or deferring that to
either the routing or some other initialization; similar to my distaste
for a trigger program doing that work, I think the Routing Data (RTGDTA)
should initiate that environment setup]. And while a DTAQ could be
waited on at the target and effect that... the DDM Server needs to be
active in either case, and the CL command to submit the request as a CL
command to the target just seems natural; esp. for OPM.
Rather than an initialization, the same effect could come from a
cleanup. Often a program designed to end *INLR=OFF will enable a code
path, such that when invoked with a special option, the application
would close all of the files. Just as with an "ask the application to
close all of the files" could be done in initialization, that request
*could* be delayed until the end. I prefer the setup to occur at
initialization, and prefer that the server job remain as-is until I
explicitly ask to tear-down, because I might want to review\debug the
job with regard to what was just performed; easier to do without having
to prevent the job from performing some automatic cleanup.
Attempted solutions...
* Files opened by ILE programs are closed successfully using
RCLACTGRP
For a typical\normal DDM application, switching to ILE [outside of
the Default Activation Group] is problematic if the application uses any
Allocate Object (ALCOBJ) of a database file via a DDMF. That is because
each ActGrp in the source job is activated as a separate DDM server job;
so unlike how a single source job would have had all locks in the same
job, the locks in the target jobs could be in conflict.
With the described atypical use of DDM, changing the programs all to
share a specific ActGrp name would be beneficial, allowing the Reclaim
Activation Group (RCLACTGRP) to effect the closes instead of coding the
application to do so; though a /special/ code-path to effect the close
of the files is generally not very difficult or of great impact.
* Files opened by OPM programs are not closed by RCLRSC (presumably
because the DDM server QRWTSRVR has the REQUEST file open and runs in
*DFTACTGRP ???)
AFaIK the RCLRSC should work the same as the request would perform
locally. So... When running the application without DDM, running on
SystemA, does RCLRSC not close the files after the I/O to the file named
REQUEST when issued in the same job? If not, then the results are
likely correct; i.e. consistent with the DDM scenario.
Hmmm.... Well.?.? Again, this scenario is not a /normal/ use of DDM
whereby the file being /opened/ are not being opened locally [except the
file named REQUESTDDM, so the above comment should apply for the target
file REQUEST; even if not for other files]. I guess I will suggest
instead, that for this particular scenario, a request to SBMRMTCMD
DDMFILE(REQUESTDDM) CMD(RCLRSC) should operate the same as if invoked
locally. Try that as a circumvention; i.e. a faux-solution [though
likely as good as a resolution], whereby a legitimate solution would be
to redesign the application to use the DDM according to what that
feature intends to provide.
* Changed the server job QRWTSRVR to DDMCNV(*DROP) - this had no
effect
* Ran RCLDDMCNV from the program on SystemB - this had no effect
The conversation in both of the above bullets, the attribute to drop
and the request to Reclaim DDM Conversations (RCLDDMCNV), I believe are
both prevented from being reclaimed because the job is still active;
"active", because the files are still open.
* Changed the prestart job QRWTSRVR to MAXUSE(1). This terminates
the DDM server after one client connection. At first I thought this
was the solution. Unfortunately the termination does not take place
until the client (SystemB) job ends - i.e. the user signs off.
If\when the conversation can be reclaimed, the job should be eligible
for reuse and thus recycle. But then, an arbitrarily small Maximum Use
(MAXUSE), is really of no help, because the job will be recycled
irrespective that setting.
If the user stays signed on and continues to make another request
for a different country then he uses the same DDM server job and the
problem with open files is still evident.
I am convinced that the problem is down to the DDM server sitting at
the top of the program stack with the Request file open and in
*DFTACTGRP
I do not think the REQUEST file is an issue; i.e. only the other
files being [left] opened by the programs called by the trigger program.
Converting the OPM programs to ILE is not viable - there are hundreds
of them!
Rarely a much simpler task than imagined. The bigger issue is that
unchanged programs are already tested, and a recompiled program is a
changed program, even if the source never changed.
Is there any way I can get the DDM server to run in a named
activation group? Any other suggestions?
If the files in the target DDM server job need to be opened in an
activation group, the programs must be ILE.
In case it was skipped, try sending the RCLRSC request to the target
system rather than simply requesting the RCLRSC on the source system;
search my reply for SBMRMTCMD. For reference:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/ddp/rbae5sbmcmd.htm>
IBM i 7.1 Information Center -> Database -> Programming -> Distributed
database programming -> Application development -> Application
development for DDM -> Using CL and DDS with DDM -> DDM-specific CL commands
_Submit Remote Command_ (SBMRMTCMD) command
"The Submit Remote Command (SBMRMTCMD) command submits a command using
DDM to run on the server system.
The remote location information in the DDM file is used to determine the
communications line to be used, and thus, indirectly identifies the
target server that is to receive the submitted command.
..."
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/sbmrmtcmd.htm>
_Submit Remote Command_ (SBMRMTCMD)
"...
The primary purpose of this command is to allow a source system user or
program to perform file management operations and file authorization
activities on files located on a target system. ...
...
Restrictions:
• File processing on the target system operates independently of
processing on the source system. Commands dependent on a specific
recursion level or request level may not function as expected.
• ...
..."
I do not believe the above noted "restriction" would be an issue for
the scenario, as described, because the server job should return to a
state that is similar to the command-line if the application were
activated locally from a command-line.
midrange.com
