Re: STDIN, STDOUT and pipes

Larry - you say user spaces vs pointers. That did not compute, since I always work with user spaces through pointers.

Are you using the user space APIs to get data from and to a user space? Yikes - that would be horrendously slow. But if you make the single call to get the pointer to a user space, then you are golden.

HTH
Vern

-------------- Original message --------------
From: Larry Ducie <larry_ducie@xxxxxxxxxxx>

Hi Scott, Richard,



So pipes aren't a good mechanism for communicating between two programs
in the same job, because (unless it's multi-threaded) the two programs
aren't running concurrently. By contrast, if they're running in
separate jobs, they are concurrent, and pipes work very well.



That all makes sense. We use pipes in some of our server jobs - our worker jobs
are sitting on a take descriptor, waiting to be passed a socket. When we want to
end the jobs we pass them a pipe. The recv fails on a ENOTSOCK so they then read
the data. The information passed down the pipe from the main server job tells
the thread to end itself gracefully. This works really well. I was toying with
the idea of using it as a buffered data store - not a good idea after all.

I shall go back to the original concept of using a pointer. I can't use
parameters or data queues because the data is xml and can easily exceed 64k. A
pointer ot temporary stream file was (and still is) the logical choice. There is
an inherent overhead and necessary cleanup associated with a stream file and
memory allocation/reallocation is associated with a pointer. As the data written
to the pointer is within a service program and the pointer is owned by a program
I will have to write a call-back process to get the program to reallocate when
required.


f it is a limit question why not use a userspace in qtemp ?

In this case, the limit will be 16Mo.



IMHO user spaces suck, but may be a good choice for this. But, if I want to
store the data in a permanent object I'd put it in a stream file. If I want a
buffer I can write to I'd use a pointer. I did some pretty extensive bench tests
on user spaces vs pointers approx 3 years ago on three different iSeries
configurations and in all cases the pointer was between 10 and 100 times faster.
The auto-extend capability of a user space does, however, give it an advantage.
But I'd rather code for the allocate/reallocate of a pointer than consider a
user space.

Again, just MHO.

Thanks to you both for your comments, and thanks for the background Scott. As
always, another piece of the jigsaw is put in place and a slightly clearer
picture emerges.

I really wish there was a C for RPG programmers course out there so we can get a
fuller appreciation of what can be achieved with ILE RPG. You guys with C
programming experience have a much broader knowledge of the system (again, only
my opinion). Learning java filled in a LOT of gaps, but C and RPG are
nuts-n-bolts languages and can be directly compared and contrasted. RPG kicks
ass but RPG programmers haven't traditionally had the exposure to the c runtime
libraries and all the goodies therein.

We could always start by getting together to create a RPG version of the header
files in QSYSINC/H. I use IFSIO_H and SOCKET_H all over the place and it would
make sense to have a "standard library" with all of the header files within it
rather than see if Scott, Bob, Joe, Jon, Barbara, or others have already posted
a prototype definition in the archive. I would venture to say that this is
something IBM should have provided when ILE was designed but I'd probably get a
slap from Jon :-).

Cheers

Larry Ducie
_________________________________________________________________
Are you paid what you're worth? Find out: SEEK Salary Centre
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2Fcare
er%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%
3Atext&_t=764565661&_r=OCT07_endtext_salary&_m=EXT
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.