Re: RPG programs as external stored procedures...

... finding the database issues would be first step and database monitor is best tool for this, as it's running the original stuff. decisions of the optimizer might change from system to system, even for every run, as available ressources and runtime statistics are part of the optimization (so running the database monitor on a production machine from time to time and have a look to the long runs, might be an idea). Another aproach could be to put the serving job (QZDASOINIT) in debug mode, this will place diagnostics in the joblog and you would see the estimates and access plan in the joblog. For static SQL you could try PRTSQLINF, this will show up the stored access plan from the last run. Some people are playing araound with Visual explain, this is the most time consuming aproach with lots of infos, but not running the original query in the original environment -nice for playing!

The Serving jobs are not ended and reused by following connects. There is some cleanup before next use, I'm not aware of an official documentation about this process.

@ACTGRP: for remote access the ACTGRP is commitscope. If you don't want to loose transaction safety, you should insure that all is running in the same ACTGRP. I'm using *caller for all commit slaves and didn't have any issues with *caller programms running in the QZDA jobs. Using another ACTGRP would have as a consequence, that a commit operation would not be recognized in this ACTGRP!!!

Creation of an ACTGRP is not the part to have a look too, the time how long the actiavtion of a pgm or srvpgm is taking could vary a lot.

D*B