Chuck - thanks for clarifying. You are correct.
Vernon - please proceed with the RFE
Edmund - while I appreciate your suggestion, that's completely out of the question - I wouldn't even consider it. That is a HUGE security risk.
Quite honestly, I don't care how difficult it is to fix this. I have to fix difficult problems every day. It MUST be corrected.
I find it completely ludicrous that RDi is using ANY part of PDM, let alone reusing commands - so the designers just decided to pick and choose which commands to reuse and which ones to ignore? Seems like they decided to do whatever was "easiest" when it comes to RDi. I find myself reverting to PDM more and more each day - many times, it's just easier.
Sorry for the rant.
-----Original Message-----
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Edmund Reinhardt
Sent: Wednesday, March 04, 2015 8:14 AM
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries
Subject: Re: [WDSCI-L] SEU Search options
Thanks for the detailed analysis Chick, you are helping me realise that
this is not simple to fix.
Yes RDi implements its search by executing a FNDSTRPDM command. We do this
on the job that is used for the RSE connection which has all the
environment (LIBL etc) set up.
To work around this I suggest creating a different USRPRF for your RSE
connection. RDi is unlikely to change its implementation since there is no
API to change FNDSTRPDM defaults.
Sent from IBM Notes Traveler
CRPence --- Re: [WDSCI-L] SEU Search options ---
From: "CRPence" <CRPbottle@xxxxxxxxx>
To: "" <wdsci-l@xxxxxxxxxxxx>
Date: Wed, Mar 4, 2015 7:03 AM
Subject: Re: [WDSCI-L] 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].
--
Regards, Chuck
--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/wdsci-l.
As an Amazon Associate we earn from qualifying purchases.