Re: SEU Search options

On 03-Mar-2015 22:56 -0600, Vernon Hamberg wrote:

On 3/3/2015 4:02 PM, Greg Wilburn wrote:

Is there any way to prevent the RDi "Find Text String" from
changing the search options in SEU? Every time I use the search in
RDi, it changes my search defaults in SEU.

The options in SEU become "OPTIONS = *NONE" (instead of 5 to
display) and "Print Records = Y" (instead of N). I like to use SEU
sometimes and this is driving me crazy.

I see this, too, and have just lived with it. It DOES look like a
candidate for an RFE, though. Polite behavior of an application - to
me - would say to put things back as you find them, especially when
it is a program doing it, not a person - SEU has always kept our
choices for future use, and this goes against that, since WE did not
make the choice.

The feature is PDM, and AFaIK [and seems confirmed by testing that] the effect is also\therefore the PDM. The /same/ effect is seen after having performed a Find String Using PDM (FNDSTRPDM) request from a command-line invocation; the Interactive Profile Entry (IPE) for the User Profile (USRPRF) name that issued the request gets updated to store the /previous/ choices for various find-string-function /parameters/. That can be confirmed by reviewing the modified values being stored in the IPE: DMPSYSOBJ The_USRPRF QSYS 0E /* if the Type is not '0E' [per my recollection faded; am too lazy to lookup], then dropping all type\subtype specifications and searching the much larger spooled QPSRVDMP output will show the IPE data */

The RDi apparently implements the "Find Text String" using Find String Using PDM, and thus the effect would be identical to if the user had requested to perform a FNDSTRPDM with those parameters. The RDi could evade the effect by issuing the find-request under a different user profile than the one used for the connection to the server [that performs the FNDSTRPDM].