Re: Compiling

Dave,

You can specify the EVFEVENT file be generated on the FNDSTRPDM using
OPTION(*EVENTF).

Best regards,

Mark Austin
IT Consultant
Universal Music Publishing International
Email: mark.austin@xxxxxxxxxx
Tel: +44 (0) 20 8742 5520
Fax: +44 (0) 20 8742 5699

Universal Music Publishing International Limited
Registered in England. Number 02050403
Registered Office: 347-353 Chiswick High Road, London W4 4HS

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx]
On Behalf Of Dave Shaw
Sent: 02 November 2007 13:50
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] 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.