× 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 too use 1 file, QPGMSRC for all RPG, RPGLE, SQLRPGLE, CL.  I've always
felt that putting a character on the end is stupid.  Almost as stupid as
the idea to put DTA or DTAARA at the end of every data area.  (Which looks
really funny in the ifs:  /qsys.lib/mylib.lib/mydtaara.dtaara).  Also helps
to avoid programs with the same name.  The only reason - the ONLY reason -
for putting a C at the end of a CL program is because you separated QCLSRC
and QRPG*SRC.  Just don't do that in the first place and you won't have
that problem.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    Tom Daly
                    <Tdaly@sddsystems       To:     "'rpg400-l@midrange.com'" 
<rpg400-l@midrange.com>
                    .com>                   cc:
                    Sent by:                Fax to:
                    rpg400-l-admin@mi       Subject:     RE: source control and 
file systems
                    drange.com


                    02/18/2002 05:21
                    PM
                    Please respond to
                    rpg400-l






I take your point about 'one giant source file' and although there could be
problems with it I think they can be overcome with a decent naming
convention.  Now what is a good naming convention is a really good
question.
I've worked some places where the member type had to be incorporated into
the name... last character 'G' for RPG or 'C' for CLP.  This to me is a
waste of valuable space.  The only instance of this scheme that makes sense
is 'L' for logicals.  This way you can use the wildcard when you want to
CRTDUPOBJ to another library.  With sensible naming I don't think this is
really that big a problem.

I've never used GREP but the scenario you laid out sounds like you could do
the same with PDM option 25 with a '2' for the 'Option' parameter.  Granted
the members won't all be open for edit at the same time....

But hey - I'm open to persuasion!


Tom

 |  From: James Rich [mailto:james@eaerich.com]
 |  Sent: Monday, February 18, 2002 17:07
 |  Subject: source control and file systems (was RE: SAA Historical
 |  perspective)

 |
 |  That creates other problems.  Now you have one giant source
 |  physical files
 |  with a huge number of members.  These members are not
 |  grouped by function
 |  or program, but alphabetically (or by date).  Unless you have a good
 |  naming convention who knows what goes with what?  And what is a good
 |  naming convention?  Granted this method does solve some
 |  problems but it is
 |  only a partial solution.

 |
 |  > I think having a hierarchy of directories to search for
 |  source members might
 |  > be overkill.
 |
 |  Imagine this:  You have all your source in /QOpenSys/mysource.
 |  /QOpenSys/mysource is NFS mounted on your computer.  You
 |  have a favorite
 |  text editor (mine is emacs, j is a cool java editor, heck
 |  even notepad
 |  would work).  You need to find all occurrences of you
 |  Super_API function
 |  call.  So you grep (hey grep again!) for "Super_API" in
 |  your NFS mounted
 |  source directory and open the resulting files in your
 |  favorite editor.
 |  Maybe your editor tracks recent files so you easily jump
 |  from source file
 |  to source file making your changes.
 |
 |  Or maybe just add a "Search directories recursively" option
 |  to search in
 |  PDM.
 |
 |  James Rich
 |  james@eaerich.com








As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.