× 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 Wed, Sep 4, 2013 at 6:28 PM, Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:
1 level or more levels really DOESn't matter, seems to me. In any case,
there have to be different names. Does it matter whether those names
are side-by-side or top-to-bottom? Not really.

For some purposes, it doesn't matter. But for some, it does.
Conceptually, there is definitely a big difference.

Multiple levels allows you to define a treelike hierarchy in a very
natural way, with some directories "parents" of others, and some
directories "siblings" of others. When every single library is a
sibling of every other library (except for QSYS), you can't do that as
easily.

Traditional databases usually don't have multiple levels, so if you
think of QSYS as "the DB2 file system" as someone else mentioned
(aptly, in my opinion), then the single-level structure is fine. And
I think this is the key. Plenty of folks are kind of "fooled" into
thinking of QSYS as "IBM i's version of Unix/Linux/Windows/etc. file
system", just as they see the command prompt as "IBM i's version of
the shell" and CL programs as "IBM i's version of shell scripts".
With that kind of mindset, QSYS is going to seem very limiting.

Fortunately, if you want stream files and multiple-level hierarchical
directory structure, you can just use the non-QSYS parts of the IFS
(as someone else also mentioned).

So to summarize: QSYS *is* limiting compared to multilevel hierarchy,
but you are not stuck with just QSYS on the i.

John

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.