Re: STDIN, STDOUT and pipes

[vhamberg@xxxxxxxxxxx]

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.