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



On Mon, Oct 19, 2015 at 12:15 PM, Justin Dearing <zippy1981@xxxxxxxxx> wrote:
The particular RPG programmer I deal with at the moment stores DDL SQL in
source members in a source file called QSQLSRC. The file has the same name
as the table. He edits the file with SEU and executes with RUNSQLSTMT.

I followed the first sentence just fine. The next two sentences make
me wonder if you've really understood the relationship between tables,
files, and members.

When you say "the file has the same name as the table", well, that's
almost certainly true. For virtually all intents and purposes, what
RPG folks call a "physical file" is, *by definition*, a DB2 table.

What I'm guessing you really mean is that your RPG colleague has a
bunch of members within the QSQLSRC file; and that each of these
*members* is named the same as the table that is created by the
executing the member using RUNSQLSTMT. To be precise about
terminology, SEU does not edit files, it edits members.

So, anyone who has been telling you that files are tables and members
are partitions isn't wrong; but it's important to understand a couple
points:

(1) Source physical files are a kind of physical file, so by
definition any source physical file is a DB2 table. But to most RPG
programmers, the mental model of a source physical file isn't the same
as that of a table. (In contrast, the mental model of a *data*
physical file member *is* very close to the mental model of a database
table.)

(2) When it comes to source, it's actually closer to think of a
"source physical file" as a special kind of directory, and to think of
a "source member" as a special kind of (stream) file. Basically,
native i programmers typically have a very flat "file system" for
source, consisting of "libraries" at the top (analogous to
subdirectories of root), "source physical files" in the middle
(subdirectories of libraries), and "source members" at the bottom
(analogous to stream files).

In case it's not clear above, you really have to be careful when you
say the word "file" when talking to native i programmers. The Unix and
Windows notion of "file" is what a native i programmer would call a
"stream file". If that's the kind of file you mean, don't leave off
the word "stream"! EVER! In a lot of contexts, "IFS stream file" is an
even clearer way to communicate the concept to a native i programmer.

I know it's a pain to be diligent about terminology, but to me it's an
even bigger pain to be misunderstood. In this case, it's easier for
the "outside world" guy to use the insular IBM i terminology than the
reverse. Think of yourself as the foreigner and the native i folks as
Americans. It's way easier for you to just "speak American" than for
them to learn your language.

So am I just learning a
pattern that this particular client uses, or am I learning a pattern that
I'll find elsewhere as I deal with different RPG programmers from different
shops?

There are a lot of different patterns. What you describe (assuming my
adjustments to your terminology) is by no means uncommon, but it's
also far from universal.

Second question, this particular RPG programmer uses TXT source members to
store SQL. Would SQLC or some other format be better? I can't find the
developer works page that tells me what all the source member types are
for.

There isn't any particular format that is *specifically* for SQL, that
I'm aware. The source type (for any kind of source) is not very
strictly enforced either. It's mainly used as a hint for PDM and SEU.
Think of it more as an annotation than a declaration.

John Y.

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.