RE: IFS in RPG

>Jim,
>Keep in mind that the files in the root file system (which is what most
people think of when you say >IFS) are stream files. They have no concept
of a record (granted, you can make your own up, but why >not use a database
for that type of information in the first place). All they are is a
collection of >bits.
><snip>
>Matt

Matt

That is true that they are a stream file with every thing that implys.
However for all we know,  DB2/400 files are stream files also,  it's just
that every tool we have to look at them(sql,dfu, dsppfm, RPG, etc)
presents them in a particualar manner.

I asked 2-5 years ago for exactly what Peter is asking for.

The point that they are stream files, that every one is different,  is a
little misleading for the following reason.   In RPG we "Assume"  the file
looks like what we/the OS said it looked like at compile time.   If I say
Level Check *NO on a file I could get unpredictable results when I read
that file if it has changed.   If I use a program described file,  I may
get unpredictable results if the file doesn't look like that when I do a
read.

Lets say Barb/Hans/George allowed us to have an F-Spec  for a stream file.
And lets say that they even gave us an I/O opcode that would parse a comma
delimited file automatically into an externally defined D/S.

I believe Hans Might say that "That's kinda iffy,  those things are not
fixed length,  You could have a problem if........"

What is the difference between that and the fact that OS/400 "Assumes"
that the layout of the file  looks like the RPG input buffer layout?    If
I did the level check no, or a program described file,   I would open
myself up for the same problems purported with Stream files.   We have been
living with that for 30-40 years.

This is the thing to keep in mind.    I would code a Ext. D/S to match the
layout of a Comma delimited file that I "Knew" very well.    There would be
NO mismatches.

And Hans,   Your or Barbara's remark of "Why not use a DB2 file"?  misses
the point,   WE are geting these files from NON-AS/400 applications !!
And we are getting more and more of them each day.


WE NEED THIS

Respectfully
John Carr