Problem with ToolKit calling replaced RPG programs

[bobbywires]

Working with an application that calls RPG programs was calling a replaced program in the QRPLOBJ library.
If you create a RPG program that someone has open the program is moved to QRPLOBJ and given a different name.
Somehow $ToolkitServiceObj->PgmCall("PGMA", "LIBA", $param, null, null); kept the pointer to the original program.
So Making changes to LIBA/PGMA doesn't work

[bobbywires]

Opps I had started a service job to run debug on the called program and didn't end it

[bobbywires]

There is still a problem - in the RPG program crashes and you have to cancel it in the qsysopr message queue you have the problem with the temp program in the QRPLOBJ library

[aseiden]

Bobby, please end *IMMED the XTOOLKIT jobs, then run your script again.

Let us know how that goes.

Alan

[bobbywires]

There are 4 of them in the QSYSWRK subsystem
I've only had to kill the one that has been used
Still don't you think this is a bug if the called program is in the QRPLOBJ library?
It can drive a programmer crazy !!
QSQSRVR QUSER BATCHI ACTIVE PGM-XMLSERVICE
QSQSRVR QUSER BATCHI ACTIVE PGM-XMLSERVICE
QSQSRVR QUSER BATCHI ACTIVE PGM-XMLSERVICE
QSQSRVR QUSER BATCHI ACTIVE PGM-XMLSERVICE

[aseiden]

Hi, Bobby,

I admit, this behavior used to confuse me. It's actually a design choice, not a bug, because XMLSERVICE gains efficiency by caching program information.

You can specify stateless mode, at least while testing/compiling, to avoid this caching. To do that, provide this line before any program calls:
$conn->setToolkitServiceParams('stateless'=>true));

Alan

[bobbywires]

Sounds like IBM "It's a feature not a bug" :)
Thanks having away around the "feature" other than killing server jobs will be a big help.

[bobbywires]

$conn->setToolkitServiceParams('stateless'=>true));
Does not work
PHP Parse error: syntax error, unexpected T_DOUBLE_ARROW in .........

[erich_hieden]

IIRC it should be $conn->setToolkitServiceParams(array('stateless'=>true));

[rangercairns]

The "XMLSERVICE programmer" advice from Allen is correct ...
1) ... end XMLSERVICE jobs and start with fresh/new job after recompiling called programs
2) ... or use XMLSERVICE stateless, so that you get a new/pool job for each php script duration

Bug? Well no ... caching XMLSERVICE "load/activate" is only way to achieve "high speed recalls" due to relatively slow IBM i program "activation costs" (want more see activation ... http://www.itjungle.com/fhg/fhg021104-story01.html). BTW -- if you are not shaking in fear at mention of IBM i activation group concept, you are IBM i superman and do not need this forum.

... long story short, when any called program is XMLSERVICE "load/activated" within private connection job (/tmp/packers) it will stay "load/activated" in current compile image state until XMLSERVICE job ends, because old compile image reference counted by IBM i until all activations end (new XMLSERVICE job will get new compile image).

Bottom line ... to avoid a long complex trip down activate/remove logic ... cough ... it was better to design XMLSERVICE for production w/cache and let "high paid" IBM i programmers earn their money with obvious IBM i talent (long live activation groups).