Re: STDIN, STDOUT, STDERR in RPG

(I may get some things wrong here - Scott may want to correct me.  I'll
tell you how understand things)

On Sun, 14 Apr 2002, David Morris wrote:

> Thanks for the help. I am still wondering
> if you don't assign a specific file handle
> to stdin/out/err, how do the utilities find
> these files? For example, it looks like QSH

Programs do not open files.  This is true of every language I know of.  A
program requests to open a file and the operating system opens it.  In RPG
the program tracks the open file by using the record format name of file
name, unless using certain APIs that track open files by a handle, just
like C.  A handle is a method the operating system uses to communicate
with your program.  The OS creates the handle, your program just has to
remember it.  So you cannot create a handle since it is not your program
that opens the files.

I believe that every program has its own stdin, stdout, and stderr.  That
these may all correspond to the same screen and keyboard is irrelevant.
The operating system creates a stdin, stdout, and stderr for every program
that runs.  Redirection and pipes simply tell the operating system to
connect the various stdins and stdouts together.

> uses /dev/qsh-stdin-null. When I asked a
> friend who is familiar with Linux how STDIN
> is identified he said that /dev/stdin-null
> is the norm, but he didn't know see know how
> Linux finds this since redirection could pick
> up STDIN from another source. How do nested
> utilities know this unless there is some
> standard file handle?

On my linux system there is no /dev/stdin-null.  I do have a /dev/stdin
which is a link to /dev/fd/0.  /dev/fd is itself a link to /proc/self/fd,
which is a pointer (in the kernel) to the process id of the currently
executing process's stdin, stdout, and stderr.  /proc/self is a link to
the currently executing process id.  There is a process id under /proc for
every executing process on the machine.  Every process id under /proc also
has the same fd/{0,1,2,3} structure, thus giving every process its own
stdin, stdout, and stderr.

If you want the output of one program to be the input of another program
you have to use a pipe.  A pipe is a system call that connects the stdout
of one process to the stdin of another.  If you want a program to use a
file as input instead of stdin (or write its output to a file instead of
stdout) then you use input/output redirection and the operating system
makes the necessary adjustments.  Your programs have no idea that they are
reading from a file instead of stdin or writing to something besides
stdout.

Regarding your question about nested utilities knowing where their
input/output is coming/going from/to, the answer is:  they don't.  That is
they don't know if stdin has been changed to be input redirection, it is
still stdin.  And they don't need to know.  They never pick up that stdin
has been redirected.  stdin is always stdin and stdout is always stdout.
The operating system is the only who knows what is going on (and hopefully
the user who typed in the command).

> I suppose I could make this easy and just use
> C, but I really want to find out how the
> utilities make this association and don't end
> up walking on each other.

I bet the RPG would be interesting.  I also bet that to use the
write-to-stdout API (I don't know what it is, QWtrStdOut or something) you
don't need to open stdout first.  But in order to use redirection I am
sure you need to run your program using QSH.  Not because QSH gives access
to stdin, etc. (it doesn't, you can run programs that use stdin and stdout
by doing CALL PGM(MYPGM) ) but because QSH provides the facility to
specify the redirection (e.g.  myprogram > /home/myhome/myoutputfile ).

James Rich
james@eaerich.com