× 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 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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.