× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Sure - the issue Greg brought up is due to the Find string or the IBM i search that RDi does - when I go to PDM and do a 25 opt against a member, the settings RDi used are in there, and they are never what I want to use when in PDM.

So a user defined option doesn't fix things that I can see. Am open to how it would help Greg's issue.

Cheers
Vern

On 3/4/2015 12:15 PM, Doug Davie wrote:
Vern,
I'm not sure I understand your question.
Can you rephrase?
-doug

On Wed, Mar 4, 2015 at 1:03 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi doug

maybe, but i only use opt 25 in PDM on green screen - it doesn't get
around the issue that I can see to add a UDO (new acronym?). And I just
don't like having the *EVENTF parm and the PRTRVDS set to Y in the opt 25
PNLGRP, etc.

But tell me more that i'm not seeing!

Vern

On 3/4/2015 9:06 AM, Doug Davie wrote:

One could also create a User Defined Option in PDM: FNDSTRPDM OPTION(*DSP)
PRTRCDS(*ALL)

On Wed, Mar 4, 2015 at 9:39 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Edmund
I'm glad Chuck replied - I had already thought that this wasn't just a
SMOP (simple matter of programming).

The workaround isn't feasible for me - I do not have the rights to create
another profile, and it'd be difficult to justify it for this kind of
thing, when the current workaround is to clear a couple fields on the
prompt in PDM.

I have to believe that something can be written to retrieve the settings
and write them back to the user profile internals - this would probably
be
a *SYSTEM level program, but it's being done now by PDM, so????

I think I will still submit an RFE later, unless Greg or someone else
does
first!

Vern

On 3/4/2015 7:13 AM, Edmund Reinhardt wrote:

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.

--
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.


--
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.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.