Hi Scott, Richard,
<snip>
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.
</snip>
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.
<snip>
f it is a limit question why not use a userspace in qtemp ?
In this case, the limit will be 16Mo.
</snip>
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%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_salary&_m=EXT
midrange.com
