× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I realize that calling using system() is not the way to go. I am not
concerned with the performance impact from using spawn(),
but what I am having trouble doing is using spawn to call commands or
programs. I do not want to ahve to code the
spawn call such that I need to give it the fully qualified path such as:
/qsys.lib/alib.lib/apgm.pgm.

Id like to figure out a way to invoke spawn to do things like:
dspusr usrprf(walt)
and have this run as a job, and capture the return code. Also, Im still
trying to figure out how to invoke using spawn commands like:
call pgm(alib/apgm) parm('parm1' 'parm2'), etc.

Is there some inheritance or environment setting I might be missing? I
already do a:
putenv("PATH=%LIBL%");
before my spawn, but I still get a spawn error stating that it cannot
find to execute what I sent to it.

Any help or ideas would be most appreciated, thanks!

Walt Fles

Simon Coulter wrote:

>
> On 28/05/2004, at 12:43 AM, Walt Fles wrote:
>
>> Im looking to call from the multithreaded job programs I did not
>> write, or that I cannot recompile (ie, run CRTPGM ACTGRP(*CALLER)) on
>> them. But that needs to be done to the called program, and not the
>> multhreaded job? Also BTW the threaded program of mine is written in
>> C, but the other programs Ill be calling can be writen in anything (
>> C, CL, RPG, COBOL ), but I have no control of them,thanks!
>
>
> You cannot do this. If any program in a multi-threaded job ends via
> exit(), abort(), or their equivalent APIs, or an unhandled exception
> occurs the entire job is killed.
>
> Your only solution is to run these other programs in a job that is not
> capable of running multiple threads. Either make the calling
> environment single-threaded or spawn a single threaded job to handle
> the program calls.
>
> Since spawning a job for each call will negatively impact performance
> you could spawn a single job that listens on a Unix-domain socket and
> pass the program name and parameters to it. It could pass received
> results back via the socket. You could also connect to the OS/400
> Command Call server and have it run the programs for you.
>
>
> Regards,
> Simon Coulter.
> --------------------------------------------------------------------
> FlyByNight Software AS/400 Technical Specialists
>
> http://www.flybynight.com.au/
> Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\
> Fax: +61 3 9419 0175 \ /
> X
> ASCII Ribbon campaign against HTML E-Mail / \
> --------------------------------------------------------------------
>
>
> _______________________________________________
> This is the C programming iSeries / AS400 (C400-L) mailing list
> To post a message email: C400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/c400-l
> or email: C400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/c400-l.
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.