Re: Compiling

Joe,

CODE has Multi-File Search, which appears to use the same facility on the System I as WDSCi. I don't think either one uses FNDSTRPDM directly, though, since there's no parameter on that command that refers to the event file - in other words, the EVENTF parameter that you mentioned doesn't exist (prompt FNDSTRPDM and press F9 for proof). I suspect (but don't know) that there's something that they call that invokes FNDSTRPDM or its supporting programs and handles the event file stuff. If I'm right, I suppose it would be relatively easy for IBM to clone that facility with a new name, change the event file location that it sets, and then change WDSCi to use the new one rather than the one that CODE uses. Just how easy 'relatively' is is the question, I suppose.

I find it interesting that Multi-File Search when run against PC files allows the user to specify the event file's name, and to delete it when done. I suspect that it came from the original OS/2 LPEX editor that CODE was based on 15 years ago. Could be that that was the inspiration for the whole event file approach to feeding information from the /400 back to the workstation.

Dave Shaw
Mohawk Industries

----- Original Message -----
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
To: "'Websphere Development Studio Client for iSeries'" <wdsci-l@xxxxxxxxxxxx>
Sent: Friday, November 02, 2007 9:18 AM
Subject: Re: [WDSCI-L] Compiling

From: Dave Shaw

Mark,

It isn't WDSCi that controls where the event file is placed. It's the
compiler that does it. Here's the V5R4 help text for OPTION(*EVENTF) from
CRTBNDRPG:

(...SNIP...)

Unfortunately, I can't find any comparable information on how the Search
function decides where to put the event file. Maybe it does use the
*CURLIB - I can't be sure. Anyone else know?

I think the compiler works okay. I haven't run into an issue there in some
time, because the event file is a multi-member file based on program name in
the library, so collisions should be avoided.

It's the FNDSTRPDM which uses EVENTF in *CURLIB, and that's where the
problems seem to crop up.

As it stands right now, I think changing this would be difficult for IBM
to justify, since it would probably involve coordination with 3 different
teams (WDSCi, compilers - which involves several sub-teams, and PDM), and
it WOULD break support for CODE, which is still in widespread use but
isn't likely to be updated for something like this. Would the gain be
worth the cost?

Does CODE use FNDSTRPDM? The only interface for WDSC would be the *EVENTF
parameter on the FNDSTRPDM, and if CODE doesn't use it, then the only one
that uses it would be WDSC.

I think it's something that could be VERY easily fixed, at least for
FNDSTRPDM. You could pass a second parameter, and that would signal using a
keyed file (or even a membered file) instead of the standard flat file.