× 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 Fri, 22 Nov 2002, jt wrote:

> | There are fundamental differences.
>
> I may be a dinosaur, James, but even dinosaurs can learn new trix...;-)
>
> I actually DO understand the difference between a DB file, text file and
> byte stream...  My question was more whether there was ENOUGH of a
> fundamental difference, to prevent them from being converted back-and-forth.

Yes, I apologize.  I didn't mean to imply that you didn't know the
differences, but I can see that my message may have suggested so.  I was
trying to point out that your question of whether or not a unix command
could be written to read a text field in a database file the same way it
reads a regular text file implies that said unix command would need to
know the structure and meaning of the database file.  Adding such knowlege
to a unix command goes against their design.  In fact it is the lack of
knowlege that makes them flexible.

> Take, for example, a Source *PF.  You and I know that they have SRCSEQ,
> SRCDAT, and SRCLIN...  But what's the complexity to "shell out" to *nix,
> convert one member to a text file, run various *nix commands and convert it
> back again...?

In fact the standard unix commands as included with QSHELL work fine with
source physical files.  It is the database files that they don't work
with.  It is this inconsistency that I feel is wrong.

> >From my understanding of this thread, it's do-able.. but looking for more
> info on where the difficulties are.

It probably is doable.  To be consistent with the design of unix commands
you could write a program that opens a database file, reads the contents,
and immediately writes those contents to stdout.  Then you would pipe
those results to the standard unix commands.  But why should we have to do
this, when the commands themselves should be doing it?  If I say:

cat /QSYS.LIB/MYLIB.LIB/MYFILE.FILE/MEMBER.MBR

it should work.  It should work for every file on the system that I have
authority to, no matter what.

However, doing the above probably won't give a lot of intelligible
results.  When working with database files we are usually interested in
seeing them, not as raw data, but as fields and rows.  That requires an
intelligent program such as DSPPFM (admittedly DSPPFM is not very
intelligent, but it knows enough to display a database file in a way that
makes sense.  A raw read of the database files the way that cat would do
it is unlikely to produce the same results).  If you want to read the
database files in a way that a database would then use the database tools
(AS/400 commands) to do so.  But there may be a situation where someone
doesn't need to read them that way.  Normally, unix commands would allow
you to bypass the design of the database.  But not so on OS/400.

By the way, this may explain why unix commands don't work on database
files:  you could easily wreck the database (not the entire thing, just
the file).  It is perfectly legal to do:

cat binary.pgm >> database.file

which would append the file binary.pgm to the end of the file
database.file.  Of course it is only legal to do so on files that you have
authority to.  But I bet DB/400 would go nuts trying to deal with a file
that had that done to it :)

> | So most unix commands are kept general on purpose so that they can be
> | flexible.  This is where I feel IBM has messed up.
>
> Well, I s'pose some still consider this a matter of opinion.  I don't,
> because IBM is running *nix and CPF/OS/400 on the same hardware...  The 400,
> not to even include the pSeries, does a decent job of running *nix, and was
> Best-of-Show at LinuxWorld.

Running unix on OS/400 hardware is not what we were talking about.  This
discussion focused on the implementation of the unix commands in QSHELL.
But you bring an interesting idea up:  I wonder what happens if you try to
cat a file in QSYS.LIB from within a linux partition or within PASE?

> But, of those who have seriously studied CPF/OS/400, my gut-feeling is that
> most see the advantages over *nix.  Sure, there are always trade-offs...
> But the idea that any one paradigm is just about as good as another
> COMPLETELY ignores TCO in the equation, as well as industry-leading customer
> satisfaction surveys year after year.

We weren't talking about TCO.  Both design philosophies work well.
Sometimes one is better suited to a particular task than the other.  But
one excellent solution to one problem does not mean that that solution is
generally "better".  Talking about TCO doesn't mean a thing until you talk
about a specific application/problem/solution.  And honestly, I'm not
trying to promote anything here.  I'm trying to point out an inconsistency
in the way QSHELL was implemented and how I think it should be improved.

James Rich



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.