Re: spawn II--the Sequel

I'm using the SMBCLIENT program call to transfer files and parsing the
stdout reponses for success/failure. Works very well, unlike QNTC. :-)

I now have the spawned job sending it's stderr/stdout back to a file in
QTEMP from the calling job so I can parse the results.

Nice !!

Thanks again for the input.

I'm also going to check into using the exit status. That could be
useful.

Regards,
Richard Schoen
RJS Software Systems Inc.
"Get the information you need. Now!"
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT


-----Original Message-----

message: 7
date: Mon, 19 Jan 2009 17:47:10 -0600
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: Re: spawn II--the Sequel

Richard Schoen wrote:

So when I call spawn(), is the job spawning as part of the same

iSeries

job or separately ?

spawn() is similar, conceptually, to the SBMJOB command. It starts a
new job, and runs a program in that new job.

However, with spawn(), the new job is a "child job" of the current one,
and will report it's status to the current job. Consider looking up
spawn() in the Information Center for more details.

What makes it really attractive in your situation is that you can start
the job with file descriptors open that map to pipes, and you can read
the pipes from your current job. You can't easily do that with SBMJOB.

But, it definitely starts a separate job.

I'm actually calling a CL program that calls the QP2SHELL to call the
SAMBA API's to transfer a file. I need to capture the STDOUT responses
so I'm thinking your RPG spawn example should work as a starting point
and I want to get the data from the pipe that captures STDOUT, correct

?

I've written quite a few RPG spawn examples -- so I'm not sure which one

you're referencing -- but I guess it doesn't matter... spawn() should
be able to run PASE programs and use it to capture the output.
waitpid() should be able to give you the exit status, as well.

That assumes you're running a Samba program -- like smbclient -- as
opposed to an actual API (calling a function in a shared library).