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



I'm curious: what benefit do you get from having a member designating a type
vs having the type designate the type (as in Duane's example)?:

On 8/14/07, Faizulla Khan <fkhan@xxxxxxx> wrote:

Duane,

We started off with several code libraries ARLIB, GLLIB etc. based on the
application area. However it was too cumbersome to maintain. So several
years ago we started moving the code into a single source library with
multiple source members. Our organization has a SRCLIB with members
QCLSRC,
QRPGLESRC, QSQLSRC, QDDSSRC, ZPrototype (all the prototypes), QCPYSRC
(copy
book sources) and QCMDSRC. This seems to work very well and is far easier
to search then to go hunting all over different libraries.

Regards
Faizulla Khan
Information Services
Grand Circle Travels
617-346-6058




Duane Kehoe
<dkehoe@weycogrou
p.com> To
Sent by: Websphere Development Studio Client
wdsci-l-bounces+f for iSeries <wdsci-l@xxxxxxxxxxxx>
khan=gct.com@midr cc
ange.com
Subject
Re: [WDSCI-L] iSeries Projects and
08/14/2007 12:27 (beginning) XP status report
PM


Please respond to
Websphere
Development
Studio Client for
iSeries
<wdsci-l@midrange
.com>






Buck,

You can solve the library issue by modifying the build CL. I have not
played with the projects perspective in a little while but did find that
things worked better when I told wdsc to create a generic build CL which
I later modified to my situation. In the couple cases I followed threw
to finish it did work fairly well, but then again I do not have any
version control system in place(can't convince the powers that be we
should have one, yet!!).

Lately, I have been thinking about trying out projects again as I look
to find a better development / organization model for code and objects.
Historically our shop has used the QRPGLESRC, QCLSRC method of grouping
by source types within a given library. This is nice but can at times
make finding all the pieces of a process more cumbersome, I still think
that is better than a single source file for an entire library that
contains many programs / processes. More recently I have been
contemplating a single file for all sources related to a given process /
program, for example LIBRARY/PROJECT with all source members together.
In my minds eye this would keep things organized and together allowing
for easier modification especially if build CLs are used(which I have
also been thinking about using as I get more modular in my design). I
am sure this may ruffle some of my coworkers thought processes but I
think it may be a good direction to go at least for modular programs as
it more closely aligns to the methods employed by other languages. I am
very interested in other developers opinions in this area, what are
others doing / recommending? Thanks in advance for any responses.

Buck wrote:
Wanted to let the list know how it's going. I'm trying to get some XP
(eXtreme Programming) techniques going in my RPG and CL programming and
I thought I'd give iSeries Projects a try, mainly for the SVN
integration. I figured I'd keep many versions of the code as I went
along.

In general, I don't think iSeries Projects is a particularly good fit
for XP. Not because there's something wrong with iSeries Projects, just
that it's probably not the right tool for the job.

The Subversion integration is okay, but mostly manual. That is, I don't
get a new rev every time I open a member for editing. And by the way,
once you've opened a member for editing under iSP, don't open it later
with RSE or SEU. Things get confused quickly, and the repository thinks
it's the member of record which will result in the loss of changes.

There's a bug trying to look at version history. If you click on a
member (say at version 14) and right click, team, history you see the
history. Click on a different member (say at version 12) and it doesn't
show the history for that member. You have to do it again.

Compilation is a pain. Again, iSP wasn't intended for a rapid edit,
compile, test cycle so I can hardly blame WDSC for my misuse of it. I
found it unpleasantly easy to compile the wrong member (right click,
remote, compile, compile.)

When ready to integrate, iSeries Projects deploys only to a single
'test' library. Not fun when one has a production deployment that goes
into multiple libraries.

All things considered, I think I'll be doing the next iteration with RSE
and skipping Subversion. I didn't get enough value out of the
experiment to stay with it for a project that is strictly RPG and CL.
If the whole shop used WDSC and Subversion, I might change my opinion,
but as a solo effort, it was more work than it was worth to me.
--buck


--

/*Weyco** Group* -/

*/Florsheim, Brass Boot, Nunn Bush, Stacy Adams/*
Duane Kehoe
EC / Programmer / Analyst


Phone # 414.908.1814
Fax # 414.908.1601
Email: dkehoe@xxxxxxxxxxxxxx


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


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