I may do that -- if I can actually reproduce the problem or figure out a smaller version.
I have recoded that EXEC as a Pipe, and CPU time went down from 226 seconds to 7 seconds. The CPU time for the REXX Level 2 I/O version can be reduced to 161 seconds by using handles and only issuing lines() once. I'm mostly concerned because I've made heavy use of SFS and I've always believed that SFS gave the client a consistent view of the file from Open to Close. If that isn't true, I may have some other code to go fix. It occurs to me that the use of lines(ifn ift ifm ) and linein(ifn ift ifm ) instead of lines(handle2) and linein(handle2) may have something to do with the problem -- maybe that forces REXX to go out and find the new file instead of the old one? On Tue, 29 Nov 2005 12:45:58 -0500, Alan Altmark <[EMAIL PROTECTED]> wrote: >Rather than calling lines() each time, try just linein() until X.1 is >null. That avoids an extra API call per record. I think the in-band way >to determine the size of the file (as opposed to the number of unread >records) is to use stream(ifn ift ifm, 'c', 'query size'). > >If you're really interested in solving the mystery of lines(), open a PMR >so our SFS experts can look at it. > >Alan Altmark >z/VM Development >IBM Endicott >=========================================================================
