Re: Question Re: Piping and Redirection -- MIDRANGE-L

jt wrote:

| [mailto:midrange-l-admin=Zwy7GipZuJhWk0Htik3J/w@public.gmane.org]On Behalf Of Hans Boldt
| Sent: Tuesday, November 19, 2002 8:40 AM

<snip>

|
| On the other hand, the stream model works very nicely for files
| involved with programming, such as program source files and scripts,
| make files, html documents, etc.
|
| Cheers!  Hans  (4 days to go before my LOA! :-)

Hans,

You mean I only have 4 more days to get my licks on Ya...?  LOL...!
(Hopefully...)

But I would beg to differ with the above...


Also, my understanding was that even the iSeries version of DB2 handled
variable character data, as well as graphic, bitmap and all that...
Question to anyone is:  What are the ESSENTIAL differences between those
field types and a stream file...?  (If necessary, could You not convert
those back-and-forth TO stream files, and use the *nix-type-a
commands...???)

The data within the database (regardless of implementation details)
can certainly be of any type or format, and can be presented to the
programmer in a variety of ways. I don't think that differs with
what I said before. The raw data in the database is stored in a form
that the database system understands. In many db products, the data
is stored in a set of files which could theoretically be read by any
program, even as streams, but understanding the content would be
difficult.

I suppose you can always convert a database to a stream of fixed
length records with a specific field layout, and process that
stream. But then, you lose a lot of the flexibility of the database.
And you still have the task of breaking down each "record" into its
constituent fields, so I'm not sure if you gain anything by
processing the database using a stream model.

"What are the ESSENTIAL differences between those field types and a
stream file...?"  I'm not sure I understand the question. A stream
is simply a sequential set of bytes. Nothing more and nothing less.
It is always up to the programs manipulating the raw data to assign
specific meanings to those bits and bytes. Unix adds one extra level
of abstraction in that streams can be processed line by line. Given
strong string handling tools (like Perl), storing and processing
data in text files can be very easy and flexible. But of course it
isn't appropriate for more complicated forms of data, like images,
sound files, and databases.

In other words, even though you could process something using a
stream, it's not always the appropriate solution for complex data.
For example, grep is great for searching relatively unstructured
text files, but SQL SELECT is more appropriate and powerful for
searching a database. (To take this a step further, how do you
search for something like a windmill in a set of image files?)

Cheers, as well, and (in case I don't wail on Ya anymore...;-), GOOD LUCK
with whatever Yer doin...!  jt

Well, no good thing lasts forever! I'll be back to work in the
middle of April. My "sabbatical" won't be all fun and games, though.
My first priority will be to look after household matters while my
wife looks after the baby. Fun stuff takes a back seat, but I do
intend to spend a good deal of time on my model train layout, as
well as various other projects.

Anyways, I will occasionally try to check in on some of these fora.

Cheers!  Hans  (3 days and counting!)