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



Kurt,

Do you have the file EVFEVENT in QGPL? If you do, is it muti-member
capable? Mine has a max members of *NOMAX. I think if you set the
attributes of EVFEVENT to hold mutliple members, your search will work
correctly.

The string you reference causes the results of the search to be placed in
the file EVFEVENT in the library that you are searching source members in.
I have an EVFEVENT file in most of my source libraries, and they are all set
to *NOMAX for number of members.


HTH

Jim

On Tue, Jun 16, 2009 at 2:54 PM, Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx
wrote:

I never got source searching to work in WDSCi, so I thought I'd try in RDi.
Looks like my issue in WDSCi was probably the same as what I'm experiencing
in RDi.

The command it built is:
FNDSTRPDM STRING($lergs) FILE(KJARLIB/QEDT) MBR(*ALL) OPTION(*NONE) COL(1
*RCDLEN) CASE(*IGNORE) PRTRCDS(*ALL *CHAR) PARM(*EVENTF)

I received the following error:
Members for file EVFEVENT more than maximum allowed.
Cause . . . . . : Member EVFEVENT was not added to file EVFEVENT in
library QGPL for one of the following reasons: -- The number of members in
the file has already reached the number of members specified for the file in
the MAXMBRS parameter value. -- The number of members in the file has
reached the system limit of 32,767 members per file. Recovery . . . : If
the file has not reached the system limit, use either the change logical
file (CHGLF), the change physical file (CHGPF), or the change source
physical file (CHGSRCPF) command to change the maximum number of members for
the file. Then try the request again.
Member EVFEVENT not added to file EVFEVENT in QGPL.

The PARM(*EVENTF) doesn't seem to be a user option in the search. It must
have a purpose, but is there any reason why we need to have this file having
more than 32,767 members? I could do as the error text suggest and set the
max members to *nomax, but is that really the best solution?

Thanks
Kurt Anderson
Sr Programmer/Analyst
CustomCall Data Systems
--
This is the Websphere Development Studio Client for 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.