RE: Accessing data in IFS

This is a very common mistake.   A file descriptor (or a socket) of zero
is normal.   The first one it assigns is zero.   Then 1, then 2, etc.

You getting a FD of zero is no different than you getting a FD (for
example) of 43.  They work exactly the same.   But somewhere in your
code (could be in the wrappers) you are treating a value of zero
differently -- and that's the bug.

Trust me, you're not alone.   Everyone makes this mistake at least once
when they're first using descriptors -- and it's hard to detect, because
when you call the program again, things work fine.


On Wed, 20 Mar 2002, Bartell, Aaron L. (TC) wrote:

> There is a programmer in my shop working on a program that opens a file in
> the IFS to read in a template for an email.  Now remember, this file already
> exists and is about 2k.  We are having very weird results to say the least.
> When we call it interactively, the first time it returns a file descriptor
> of 0.  The second time we call the program it returns a file descriptor of 3
> and we get the desired output.
>
> Any ideas?  I should mention that the open api is wrapped in a module.  The
> module contains the code that came from "Who knew you could do that with
> RPG. . ." for the open(), read(), write(), and close().
>
> So right now to fix the problem she calls the #Open procedure twice which in
> essence is calling the open() api four times(open, close, open; open, close,
> open).
>
> It is almost like it can't find the file the first time, but the second time
> it finds it just fine.
>
> Aaron Bartell