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



This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Always keep your data separate from your programs.  This will allow easier
testing.  Let's say you have three libraries:  PRODPGMS, PRODDATA,
TESTDATA.  Now if your library list contains PRODPGMS and PRODDATA you
will be working with your production data.  Replace PRODDATA with TESTDATA
in your library list and now you are working with test data.
There are some exceptions to this rule.  Trigger programs should be in the
data library.  Or when they spawn a new library they'll screw up the
trigger for sure.
For clarification, I consider print files and display files to be in the
program library, not the data library.  Data area's, data queue's, user
spaces, etc all go into the data library.

I like keeping all programs in one source file:  QPGMSRC.  I've had a few
programs clobbered because someone compiled a CL with the same name as a
RPG program.  I don't like the silly rule that a CL program should end
with C in it's name.  We already have an object type of *PGM.  We already
have a subtype of CLP.  If you don't have different source files then what
benefit does having the C in it's name buy you?

You may want to consider putting all data definitions into one source file
also.  This way if the file was created using CRTPF or RUNSQLSTM the
fellow trying to recreate it doesn't have to search multiple files.

Yet another reason for a good change management system.

You could get really sadistic and say the source names and object names
should never match.  This will help stop the person who does a CRTRPGPGM
when he should have done a CRTRPGMOD and either a CRTPGM or UPDPGM to get
the rest of the modules together.  You can bet your bottom dollar that I
will not name a program after a main module if there are multiple modules
in a program just to avoid this situation.

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




"Rusty Luse" <rluse@cronus.cc>
Sent by: midrange-l-admin@midrange.com
10/03/2002 09:14 AM
Please respond to midrange-l


        To:     <midrange-l@midrange.com>
        cc:
        Fax to:
        Subject:        Library and Source File Question



I am in the process of setting up some standards for creating libraries,
source files, objects, etc.  I have two questions that I would appreciate
some help with.

1.  Is there a major pitfall that I may encounter if I choose to setup a
library that will contain all objects for a particular application?
     This library would include all program objects and data files. Should
I separate my data files into another "data" library?  Half of my
     coworkers think we should separate the data and objects while half
think it is easier to keep everything in one library.  What are the
     advantages and disadvantages?

2.  This question is similar to the first question except it deals with
source files.  Many of my coworkers believe that we should keep all
     of our source in one source file instead of separating them by
QDDSSRC,
QCLSRC, QRPGLESRC, etc.  I prefer to separate my
     source but am not against changing if one source file is better.  Any
suggestions?


Thanks,
Rusty

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





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.