Re: DDM Server QRWTSRVR and OPM Programs

Rather than having the Trigger program "call" the OPM programs, consider
having it "submit" Jobs that "call" the OPM programs - any opened files
will be closed when the Job ends.

If Clients in System B need a response, have the "submitted" Job place an
entry on a data queue keyed by Request ID. Have the Trigger program wait on
the keyed queue.




On Wed, May 28, 2014 at 8:46 AM, <rob@xxxxxxxxx> wrote:

Both of these suggestions sound much more elegant than having your
QRWTSRVR swap profiles to someone with job control authority and self
immolating with
ENDJOB JOB(*) DELAY(10)


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: Scott Mildenberger <SMildenberger@xxxxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/28/2014 10:31 AM
Subject: RE: DDM Server QRWTSRVR and OPM Programs
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Does the trigger program need to wait for the called program to finish? If
not, it could be submitted to batch with the proper library list. Another
option that would require more work is for the trigger program to put the
request on a data queue - separate one for each country. Then there would
be programs that monitor the data queues and process the requests - each
one would have the appropriate library list. If the trigger needed a
response that could be through a data queue also. Both of these options
would mean that the trigger program would never need to change its library
list and wouldn't have files open.

Scott

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Sadler, Pete / Kuehne + Nagel / Ntg CI
Sent: Wednesday, May 28, 2014 7:38 AM
To: midrange-l@xxxxxxxxxxxx
Subject: DDM Server QRWTSRVR and OPM Programs

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


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


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