|
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
As an Amazon Associate we earn from qualifying purchases.
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.