Re: recommendations for faster IFS and string handling sub-procs.

Scott,

Thanks, this is just the kind of thing i was looking for.  I cobbled this
stuff together in a day or so from examples I found in the archives, and
partly (and as it seems, wrongly ;) from your ftpapis.

see comments in line

> Instead, pass the variable by reference.   Then, doesn't have to allocate
> new memory for it, it doesn't have to make a copy of it, etc.  that
should
> make a difference in performance.
<snip>

I was pretty sure i wasn't doing this well.

> Okay, here's that 32k return value that I was complaining about before.
> (Hmmm... "peFD","peEOF"??  That's the same naming convention I use!!)
> Instead, I'd pass the parms like this:

that's because I stol... I mean borrowed some of it (at least in spirit, if
not in substance) from your ftpapi stuff.. ;)

> I made the EOF indicator the return value.   Since that's only 1 byte,
> the time it takes to make a copy of it is totally insignificant.  This
> also gives you another advantage, you can use it in a DOW loop or IF
> statement.

ok, I like that idea better.

> Furthermore, because it's options(*varsize) you don't always have to
> declare your caller's variable as 32k long.   If you wanted it to be
> only 100 bytes for some records, it would still work.

> That variable size is also why I added the peMaxLen parameter.  Since
> we're allowing various sizes to be passed, we can use peMaxLen to make
> sure we don't overflow the ACTUAL size of the variable.

I thought that keyword varying did that for you - that it didn't pass the
entire variable, only what was filled in.

I was very unclear on the diff between varying and options(*varsize).
thanks for clearing that up.

> > C                   dou       Char = x'0A' or Char = x'0a'

> Hmm... this is probably a bug, but...  why are you checking it for x'0a'
> twice in the same statement?!    This makes no sense.   They're the same
> thing.

not a bug, it was intentional - i wasn't sure if hex values were case
sensitive - now that I think about it - duh! I stand corrected.

> The downside to the _C_IFS_fopen() family of functions is that they're
not
> as versatile (IMHO) as the open() family.

could you elaborate on the pros and cons of the f_ functions vs the others?
what about them is less versitile?

> > C                   if        Length > 0
> > C                   call      'QDCXLATE'
> > C                   parm                    Length
> > C                   parm                    String
> > C                   parm      'QEBCDIC'     Table
> > C                   end

> If you open the file with O_TEXTDATA defined, you shouldn't need to
> manually translate it to EBCDIC.    That should perform a bit better.
> If nothing else, using iconv() instead of QDCXLATE will perform better
> becase you'd be calling a service program instead of loading/running a
> *PGM object.

This was a leftover from what i stole.. I mean borrowed... from the
archives.  it did the trick, but thanks for the heads up on O_TEXTDATA.

you know what they say, plagarism is the sincerest form of flattery!

> >  * Return that line
> >
> > C                   eval      StringOut = %trimr(String)
> > C                   return    StringOut
> >

> I don't understand why you're trimming StringOut.  Wasn't that a varying
> field?!  why would it have trailing blanks?   And if it does have
trailing
> blanks, you probably wanted to keep them!

i didn't trim stringout, only string - string was the parm to QDCXLATE (not
varying) and stringout was varying and the return value of the subproc.

by not using the qdcxlate, I can eliminate this part.

> As for your field parsing routines, I'm going to have to pick those apart
> tomorrow or something, since it's now 2:00am, and I'm suddenly REALLY
> tired...

Please, don't go out of your way and ruin your weekend, you've done a ton
already.

> But, I think I've probably given you some food for thought.

Very much.  Thanks again,

Rick