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



Simon: I've already put it to bed...not going there. Somehow my RSS Reader
missed Scott's original response post, so I didn't see his example, but I
found it in the archives. After seeing the process, it's not worth the
effort (for me, at least).

Scott: Thanks for the example. Yeah, QMODSRC...pretty neat, eh? I decided
on this approach because of a personal foobar. I was testing something when
I was still very new to the AS/400 (yes, that was still it's name). I
wondered what would happen if I created a program from a member in source
file QCLSRC called TEST and had it call a program created from a source
member in file QRPGSRC called TEST. So, I compiled one, then the other. I
thought it odd at the time that when I compiled the first program (PDM
Option 14) it did not prompt me to delete anything, but the second one did.
I, of course, answered "Yes, please delete that object" on the second
compile. Each compile resulted in creating a *PGM object called TEST, in
the same library. Of course, IBM is smart enough to not allow two objects
of the same type and name, so it deleted the first and created the second.

Needless to say I learned a lot in those 10 minutes (namely, last program to
compile wins!). That got me thinking (which is no small task). IMHO, IBM
should have named source files based on the object type being created in
order to eliminate the likelihood of name conflicts such as I had come
across in my TEST example above. In a way, they did this with QDDSSRC, as
normally all *FILE object source goes there (of course, perhaps they should
have named it QFILSRC).

Anyway, that's my cock-eyed way of thinking: one source file for each
object type. The analogy breaks down a little for things like REXX, and SQL
that I run through RUNSQLSTM (QQMQRYSRC would hold *QMQRY source members),
but it keeps my head on reasonably straight. So, in my QMODSRC file I have
source types of CLLE, RPGLE and SQLRPGLE. If I knew C or used COBOL (my
first love), those source members would go there too. Although my naming
convention would preclude conflicts, there is no chance if they are all in
the same source file.

I guess that's what I was thinking with QCPYSRC. Even though the source
types there are typically RPGLE (just like many in QMODSRC), there are no
related objects. Members in QMODSRC relate one-to-one with objects, QCPYSRC
don't. I could have left the copy books in QMODSRC, just chose not to.

Again, this is just my way of doing things after 20+ years of trial and
plenty of error. I thought the compiler directives would allow me to
eliminate one source file (and that would be true), but after further
review, the copy books are cleaner, so QCPYSRC stays for me.

Thanks again to all,
--Bruce Guetzkow




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.