Hi Rob, thanks for the prompt reply.
You are correct, I should have said 'A trigger program attached to the REQUEST file on SystemA is
activated and maps the request record from the trigger buffer to a data structure'.
The trigger program does not open the file.
I thought my post was getting a bit long so I tried to simplify it!
When I look at the jobs open files the REQUEST file is actually opened by the DDM server.
However, the main problem is the other country-specific files opened by the OPM programs.
Pete.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: 28 May 2014 15:06
To: Midrange Systems Technical Discussion
Subject: Re: DDM Server QRWTSRVR and OPM Programs
Still looking at this...
However let me pick the first nit.
Why are you reading the file? If the program on the target system is truly a 'trigger' program it will contain the entire record buffer as one of the parameters to the trigger program. That has all the data you need.
If you do not have to read the file you'll never have I/O to the file.
Thus the file will not be left open.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Sadler, Pete / Kuehne + Nagel / Ntg CI"
<Pete.Sadler@xxxxxxxxxxxxxxxx>
To: "midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>
Date: 05/28/2014 09:51 AM
Subject: DDM Server QRWTSRVR and OPM Programs
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
I am having problems with files being left open in the DDM server job
QRWTSRVR.
Here's the set up...
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 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!
Attempted solutions...
* Files opened by ILE programs are closed successfully using
RCLACTGRP
* 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 ???)
* Changed the server job QRWTSRVR to DDMCNV(*DROP) - this had no
effect
* Ran RCLDDMCNV from the program on SystemB - this had no effect
* 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 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
Converting the OPM programs to ILE is not viable - there are hundreds of
them!
Is there any way I can get the DDM server to run in a named activation
group? Any other suggestions?
Many Thanks,
Pete.
midrange.com
