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


On Sat, 14 Jun 2003, Richard B Baird wrote:
> > 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.

No.  When you do varying, it passes the entire variable.  varying is just
a way to tell opcodes to ignore the data after a certain length.  This
way, you don't have to pad it with blanks, and then strip those later,
etc.  The entire data in the variable is still there, just some of it
is ignored.

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

Is it clear now?   options(*varsize) means that you can pass only part
of the length of the parameter if you like.  varying means that the whole
parameter is passed, but a part of it is ignored.

if you have "32765A varying" as a parameter, then the caller must also
specify a variable that's "32765A varying", and pass that as a parameter,
or they will get a compile error.

If they have a "256A varying" that they want to pass instead, you also
need to supply options(*varsize) to tell the compiler that you're willing
to accept a smaller variable.

But the problem that THIS creates is that you've got a 32k varying, how
do you know that you need to limit the parameter to 256 bytes?  Especially
when you write your service program code before the calling program has
even been written!

and that's what that extra parameter, peMaxLen is for.

> > > C                   dou       Char = x'0A' or Char = x'0a'
>
> 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.

Yes, 0a is just a number.  We think of it is the number ten, because we're
used to decimal numbers.   But whether it's x'0a' or x'0A' or X'0a' it's
still ten.

> > 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?

Okay, I was thinking in terms of Unix when I said that.  open() can be
used on many devices.  Such as serial ports, tapes, CD-Roms... you can
read at a level below the filesystem if you like...   Etc...  fopen() is
limited to character devices.

This does not appear to be true on the iSeries.  In fact, you have to use
fopen() instead of open() if you access a tape or save file.  In fact,
there are even two different fopen() functions, one is _C_IFS_fopen()
and the other is just fopen().  The first is for IFS, the other is for
record-style files in the traditional filesystem.  It's very different
than Unix!

in Unix, open() & friends are direct system calls.. you're calling a
routine in the kernel. Whereas fopen() is part of the C runtime library.
On the iSeries, open() & friends are part of the UNIX-type APIs, and are
in the system API binding directory -- which means it's automagically
available to your program without specifying the binding directory.

Whereas, fopen() would require binding to QC2LE binding directory, which
isn't a big deal since it's automatically installed on every AS/400.

I see that in ILE C, there are all sorts of extensions to fopen() to allow
you to specify things like ccsid, arrival sequence, etc, that don't exist
on other platforms, so it may very well be that fopen() is more versatile
on the iSeries than open() is!

I guess at this point I'd recommend opening the file with fopen() and
reading with fgets().

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

Actualy, I'm flattered by your use of "pe" to prefix parameters, and
using "*++++++++" at the top of subprocedures.  I think it's great that
you like the way I do things!