× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




Hmmmm....

"Simplest" is a tricky subject for me. So often, when someone asks for something to be "simple" what they're looking for is a method that has a shorter learning curve. Is that simpler? It can be, but I think there's another way to interpret "simple."

To me, copying the IFS data to a PF is never going to be a "simple" solution. It creates all sorts of new problems that you have to find a way to work around.

a) Two people can't run the same program at the same time, since they have to clear a PF, and copy data to it. Granted, there are workarounds, such as using QTEMP, or uniquely named PFs. But the workaround makes it slightly less "simple."

b) If something goes wrong with the CPYTOIMPF, how do you troubleshoot it? How do you know exactly where it failed? How do you report a meaningful error to the user? Yes, there are ways to extract that info from the job log, or simply point the user there, but again, this makes it less "simple". Especially when the file you need to view to see what happened is in the user's QTEMP job!

c) Then there's the performance aspect. Copying a file before you can read it, requires extra time. Granted, if the file is small, it may not matter. But for a large file, this time can cause the user to think something's wrong, maybe calling for support, or (my favorite) turning the computer off to "reset" the problem (GRRRRRR!!). In the middle of the conversion! Again, this can be solved, but what about simplicity?

d) Finally... with a VERY large file, disk space could be an issue. Having two copies of a file instead of one copy, can matter. Though you probably aren't processing a file that's quite that large, I'm guessing.


I could go on.. there are lots of things that CPYTOIMPF doesn't handle very well. Sure, there are workarounds, but each situation makes it that much less simple.

Once you get comfortable with reading files in the IFS directly from your RPG program, it's not significantly harder to do than reading a PF directly from your RPG program. Yes, there's a learning curve. So to many, this means that it's less "simple". YMMV.

Ack!  How did that pesky soap box get underneath me again?  Sigh.

I recently wrote a sample program for parsing pipe delimited files that was intended to be a sample program that someone else could use, someone who was also parsing a pipe-delimited text file. Perhaps you could adapt it to your needs http://www.scottklement.com/rpg/PipeDelim.zip

The code does a few extra things that you didn't say that you needed. It was written in response to a conversation in the System iNetwork forums. If you're interested in the full story behind the code, you can read that conversation at the following link:
http://www.systeminetwork.com/isnetforums/showthread.php?t=46679


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.