RE: DDM Server QRWTSRVR and OPM Programs

The data queues can be keyed by user, job #, or whatever makes sense. You could use the SBMJOB option, just need to setup a mechanism for feeding back the results to the trigger program which will wait for the result.

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 8:40 AM
To: Midrange Systems Technical Discussion
Subject: RE: DDM Server QRWTSRVR and OPM Programs

The trigger program does need to wait because the called programs return data to it.

I had considered having separate request files for each country, until I counted 127 of them !
I fear that having a data queue for each country would be just as unwieldy.
The other problem with the data queue solution arises because there can be multiple users on the client machine.
If two users were doing requests (and needed replies) for the same country then one user could conceivably get the queue entry for the other user.

Pete.


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Mildenberger
Sent: 28 May 2014 15:31
To: Midrange Systems Technical Discussion
Subject: RE: DDM Server QRWTSRVR and OPM Programs

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