RE: IFS in RPG

Matt,

I code in a number of languages and so I understand that IFS files are stream 
files.  There are a number of ways this could be handled in RPG, and I really 
don't see it as a code issue, although it may be a design issue.

Such as perhaps allowing us to put a record length in the F spec, which would 
be used as the number of bytes to read for each read.  The simples would be to 
create a native RPG read BIF that would look almost exactly the same as C's 
read statement, %Read(FileName: BufferPtr: NumBytes); If you want to make it 
fixed format, Opcode ReadIFS(e), Factor1 NumBytes, Factor2 FileName.  Same with 
a write.

As for... "The prototypes... take up about a dozen lines and another 30 
lines...".  So that's 42 additional lines, I was being generous when I said 
25-30.  That just makes my point.

This:
If you really need to do the type of access to a stream file that setll type 
operations imply, wouldn't it be better in most cases to just put it in the 
database?

I really wouldn't, but I'm in the habit of doing a *Loval SETLL whenever I read 
thorough files, even though the file should start on the first record.  Same 
was as I get into the habit of initializing fields I don't have to.  Just my 
coding style.

Again, I'm not saying that this is 100% necessary and should be Rochester's top 
priority, I'm just saying it would make it extremely easier to code to IFS 
files than currently, and a lot more people would start coding to IFS.  If I 
ever need to code to the IFS I'll just do the research, write the prototypes, 
etc.., get code samples and do it.  So I'm looking at... 3 to 4 hours the first 
time I want to code to an IFS file.  If they were native RPG it would take me, 
what, 15 minutes to look up the opcodes?

Regards,

Jim Langston
Programmer/Analyst
NT Administrator
Cels Enterprises, Inc.
(310) 838-2103 x604


-----Original Message-----
From: Haas, Matt [mailto:Matt.Haas@thomsonlearning.com]
Sent: Thursday, July 11, 2002 1:44 PM
To: rpg400-l@midrange.com
Subject: 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.

The prototypes for basic operations only take up about a dozen lines and 
another 30 lines or so for constants for the open() API. You could easily put 
them in a separate file to copy in so you only do this once and likely will 
never have to touch them again.

The open() API does take several lines to populate the fields for the various 
flags and the file name but how's that worse than defining a key list and 
populating it? Writing to a stream file takes one line plus whatever you put in 
for error handling (which you need to do with the native database methods 
anyway) and a close is one line plus error handling. So it is it more lines of 
code? In most cases yes, but not that much more and the bulk of it can be in a 
separate file that you include in the source.

If you really need to do the type of access to a stream file that setll type 
operations imply, wouldn't it be better in most cases to just put it in the 
database?

Matt