RE: *CURRENT library? was RE: (no subject)

Thanks, Phil

What do they say? Don't ask why? As you know, *CURLIB is troublesome. E.g.,
our build programs will sometimes change it. I'll need to check that it's
still OK to do this while using CODE. For now, I assume it's alright to
change it in the session, once it's started.

Re: changes - CL prompting right now requires a STRCODE session - doesn't
work with autostart server. Is this right? Does prompting work without
STRCODE in the RSE connection?

As I know you've heard, and I'm sure you are aiming for, RSE has to have
the full functionality of CODE. You already have LPEX in RSE, and CODE is
based on LPEX, right?

We're just starting to move in this direction. Personally, I've struggled
(and given up many times) with earlier versions. We're definitley looking
at using the Distributed Debugger. Looking forward to further developments.

At 08:33 PM 10/12/02 -0400, you wrote:

Vern, whether you use STRCODE or the autostart servers for CODE tools, you
still require
a unique curlib. This is not a bug, it is a design point. It may be a
design flaw, but is working
as designed. I won't comment on how it came to be designed this way :-). We
did hope the
lifting of the 25 library limit in the library list would help with the
resistance to this requirement,
but it is clear to us it has not.

The "new communications in WDSC 4.0" that Hak refers to is the Remote
System Explorer
(RSE) perspective in the IDE. This will eventually replace the classic CODE
tools, and it is based
on an entirely new communication layer that has not inherited the design
requiring a unique
curlib per user.  So, to the extent you only use the new IDE and its
built-in editor, you do not need
a dedicated current library. However, if you launch a CODE tool from the
RSE, such as the CODE
Editor, then you are using the old comm layer with the same restrictions.
We need to provide you
is a rich enough environment in this new world that you no longer feel
compelled to launch the
CODE tools... we are not there yet. The next release will move that ball
foreward a considerable
degree.

Phil Coulthard, iSeries Software Architect,  IBM Canada Ltd.
coulthar@ca.ibm.com. 905-413-4076, t/l 969-4076