|
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 mailing list archive is Copyright 1997-2025 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.