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



The FNDSTRPDM command  (which the WDSC search function uses) automatically
generates the events file in  *CURLIB/EVFEVENT member EVFEVENT
So if multiple users have the same *CURLIB, then it is possible that
conflicts may occur.
I have opened a requirement to see if we can get the FNDSTRPDM command
changed to allow specifying the target events file.

thanks,

Violaine Batthish
WebSphere Development Studio Client, IBM Toronto Lab



wdsci-l-bounces@xxxxxxxxxxxx wrote on 02/21/2007 09:32:56 AM:

Joe, I think WDSC uses the EVFEVENT file in the *CURLIB of the
connection.

Then again, I have also had this error even though I was the only WDSC
user on the system (since the last IPL).

Peter Colpaert
Application Developer
PLI - IT - Kontich, Belgium
-----
Yoda of Borg are we.  Futile is resistance, assimilated will you be.
-----



"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
21/02/2007 15:30
Please respond to
Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>


To
"'Websphere Development Studio Client for iSeries'"
<wdsci-l@xxxxxxxxxxxx>
cc

Subject
[WDSCI-L] Problem with multiple simultaneous searches






I was just giving an onsite class on WDSC to a group of nine RPG
programmers
and while they were generally pretty enthusiastic about the tool, we did
hit
one really nasty snag.

At one point, I had the entire class do an iSeries Search.  At that
point,
odd things happened.  Some people got other people's results, and some
people got the following error:

"EVFF9007E: Cannot remove and create member EVFEVENT in file
QGPL/EVFEVENT
to hold the search result.  Release the file and try again."

Hmm.  It seems like all search requests hit the same member.  They should

at
the very least be different members for different connections (you could
use
the job number of the connection job as the differentiator).  There are
issues with cleaning up those members when the jobs end, but there are
ways
to handle that (e.g., you can register a cancel handler for the
connection
job).

Anything is better than everybody sharing the same member.

In our class, we had people searching two source members in their own
library for a string; some people got results from other libraries, and
some
didn't get anything at all or got the halt mentioned above.

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