Re: SEU Search options

On 04-Mar-2015 15:37 -0600, Greg Wilburn wrote:

<<SNIP>>

I just don't understand why RDi has to mess with the settings at all.

Again, the FNDSTRPDM is responsible for updating the IPE.

In fact, I can recreate the scenario where it does NOT change the find
parameters in PDM. If I'm actually in PDM on the green screen when I do
a Text Search in RDi, nothing changes in PDM option 25.

The defaults actually were changed by the FNDSTRPDM [issued via RDi or not] such that a *new* invocation of PDM [even in the same job] would /see/ those changes; while working within the active PDM session, the changes to the IPE will not be visible. The active PDM session, like other /session/ functions storing /operational-preferences/ will perform an effective IPE_load() function into local run-time variables upon entry and then upon exit will perform an effective IPE_store() function; the /load/ retrieves what are the /previous/ values and the /store/ copies the current run-time values into the IPE to become the new /previous/ values. Dump the IPE after starting PDM, and then dump the IPE again after the FNDSTRPDM [from RDi or CmdLine for example], and the difference will be conspicuous; i.e. the effect of the effective IPE_store() function of the parameter specifications made on the FNDSTRPDM will clearly have replaced those parameter-values that remain active only within the active PDM session.

So why not just "tell RDi" that the user profile is in PDM?

As described above how the preferences are managed, the presumption that the issue is preventable by being "in PDM" is false, and thus is not a workable solution. Again, the possibly best solution is to have a means externalized via the FNDSTRPDM enabling the invoker to request *not* to effect the IPE_store() function when that invocation completes.