Re: Current library question

Adam,

I believe you're correct - at least, it matches my experience. The last
time I tried it, Search also was still creating the EVFEVENT with
MAXMBRS(1), which is one of the old problems that people have encountered
repeatedly. It's been a while, though, so maybe that's been fixed. That's
actually in the FNDSTRPDM code on the i, though, not in WDSCi/RDI itself.
I'm not sure if there's any real contention with searches if multiple
programmers use the same *CURLIB - that would be worth checking.

I think the main reason to have separate *CURLIBs is to be able to use the
CODE/400 tools. I rarely use the editor anymore, although I do still like
the CODE comparison tool better than any of the alternatives, but I use the
CODEDSU screen/print file designer frequently. CODE puts the STRCODE user
space in the *CURLIB, and you can't share that between programmers as it's
specific to your PC's connection.

So, my opinion is that if you never use CODE you can probably get away
without having a separate *CURLIB for each developer, unless there are
problems with searches that I'm unaware of. If you do use CODE, you
definitely need separate *CURLIBs.

Dave Shaw
Mohawk Industries


----- Original Message ----- From: "Adam Glauser" <adamglauser@xxxxxxxxxxxx>
Newsgroups: midrange.wdsci-l
To: <wdsci-l@xxxxxxxxxxxx>
Sent: Friday, September 26, 2008 9:26 AM
Subject: Re: [WDSCI-L] Current library question

Buck wrote:

Jerry Adams wrote:

What "stuff" are you talking about, Jim? Although my current library
isn't QGPL, there's nothing from WDSc in my *CURLIB. At least, not
unless I tell it to do it.

EVFEVENT holds the information from the compiler. That lives in *CURLIB.
--buck

I thought that the EVFEVENT files for compiles were in the library in
which the object is created?

I think it is the 'Search iSeries' function that uses *CURLIB for its
EVFEVENT file.