Re: DDM Server QRWTSRVR and OPM Programs -- MIDRANGE-L

My .02...

This has all the hallmarks of using a hammer to drive a screw.

It seems has if your using DDM files as a roll your own messaging system.

The best solution would be an actual messaging system such as IBM's MQ...

If you're not willing to pay for a production ready messaging system, at
least consider using DDM data queues instead of DDM files.

This is a nice intro to messaging & queueing...
ftp://ftp.software.ibm.com/software/mqseries/pdf/horaa101.pdf

If you chose to roll your own, consider the consequences of failures in the
network and the endpoint systems (jobs). The support you may need for
robustness is what you're paying for in the MQ product.

Lastly, be very, very sure that the requestor really "does need to wait
because the called programs return data".

Sometimes you have no other choice, but that means that the requestor can
be stopped in it's tracks by network or remote system issues.

Charles

On Wed, May 28, 2014 at 9:38 AM, Sadler, Pete / Kuehne + Nagel / Ntg CI <
Pete.Sadler@xxxxxxxxxxxxxxxx> wrote:

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.