|
Hi Joel, Why would I lose the ability to use string variables for file names? How about fXYZ ipe i disk usropn path(fldname) then c eval fldname='/home/abc.txt' c open XYZ One point of all this is to avoid having ten thousand programmers all write different procedures that do essentially the same thing. Another point is that every example people give of how easy the API's are is an example of output, i.e. writing to the IFS. Show me a simple example of reading a line of text (i.e. data followed by carriage return line feed) using the API's. Then compare it to d Data1 ds d TextFld 1024a varying c read XYZ Data1 Now imagine you want to read a .csv file with lots of numbers in them, e.g. 123,456.78,23,104568.20-,134.4343,134234,08797,0789.99 Would you rather use the API's or something like the following: d Data1 ds d Nbrs 31p 9 dim(20) c read XYZ Data1 Now imagine you have 5 different programmers trying to solve the same problem. How many different procedures would you get? Having the native I/O routines handle the data parsing and conversion for us would go a long way towards answering your 2nd concern about handling the data once it's been read. Peter Dow Dow Software Services, Inc. 909 793-9050 voice 909 522-3214 cellular 909 793-4480 fax ----- Original Message ----- From: "Joel Fritz" <JFritz@sharperimage.com> Sent: Thursday, July 11, 2002 1:49 PM Subject: RE: IFS in RPG > Seems to me that bifs to wrap the Unix Type file APIs wouldn't be a bad > thing. It would standardize things nicely. OTOH, the prototypes aren't > arcane. I don't think being able to put the file name on an F spec would be > as helpful as it may sound. One thing you lose immediately is the ability > to use string variables for file names. I've always found that to be the > only annoying tradeoff in RPG file I/O. > > Stream files are harder to deal with than database files. There's no way > around it. Opening, closing, reading, and writing are the easier parts. > The harder part is parsing and manipulating the data once you get your hands > on it.
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.