× 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.



Dave,
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 inC,
but theother programs Ill be calling can be writen in anything ( C, CL, RPG, COBOL ), but
I have no control of them,thanks!


Walt

Dave McKenzie wrote:

This sounds familiar--I've had the same problem in a multi-threaded app I work on. I think the problem is that "mypgm" runs in a *new activation group. ACTGRP(*NEW) is the default on CRTPGM.

There's a note at:

http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/rzahw/rzahwterco.htm

that says:

"The default activation group attribute for a program is *NEW. Calling a program with a default activation of *NEW in a multithreaded job ends both the activation group and the process when the program ends. If the job is to remain active after the progam ends, the program should be changed to use the *DEFAULT or a named activation group."

The fix for my app was to use CRTPGM ACTGRP(*CALLER) on the called pgm.

--Dave


On Wednesday 26 May 2004 09:07, Walt Fles wrote:


CPF1241 just indicates that the job ended abnormally. Were there any other
messages in the joblog ?


No it does not Here is a description of the problem:

I have a small test program,that does this:

system("call pgm(mylib/mypgm)");

That works, I get the output I expect, etc.

Now in order to reproduce the problem, the scenario is as follows:
This is the source code for mylib/mytstpgm, that calls to execute
mylib/mypgm:

#define STR "call pgm(mylib/mypgm)"
thread_function( void *parm) {
   system( ( char * ) parm );
   pthread_exit(*parm);
}

main() {
       pthread_t id;
      pthread_create(  &id, NULL, thread_function, ( void * ) STR );
       pthread_join( id, NULL );
       printf( "Launch Complete" );
}

I complile the program using CRTBNDC, and launch the program as follows:
sbmjob cmd(call pgm(myllib/mytestpgm)) ALWMLTTHD(*YES)
Because that is the only means I can find to invoke this job
multi-threaded.

When the program executes, I get the output I expect from "mylib/mypgm"
but then "my/lib/mytstpgm" dies before I get the printf after the
pthread_join.

If  I change the #define to an OS400 command, ie, a "dspusrprf
usrprf(walt)",
I get the output as Id expect, and the program executes completely.

It appears that I have nested "calls", ie, one in the sbmjob command
line and then
another in the system() function call invoked by the thread.  Im
thinking that when the
inner most "call" terminates it kills the parent function as well.  I
cannot do this using
spawnp() I don't think for intrinsic functions and user programs that
are invoked by
call pgm(lib/pgm ).

Any help would be appreciated, thank you!

Walt Fles

Hall, Philip wrote:


-----Original Message-----
From: c400-l-bounces@xxxxxxxxxxxx [mailto:c400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Walt Fles
Sent: Wednesday, May 26, 2004 10:21 AM
To: C programming iSeries / AS400
Subject: Re: [C400-L] Program ends, no messages, logs, etc

Is it possible for a submitted batch job to run out of stack space, and
cause this problem?
Is there a compiler option to increase the stack space for a job?

Thanks!

Walt Fles wrote:


I take that back,
the program that invokes the thread that does the system() call
ends,with a message CPF1241.
Would be nice if I could see where or how it was stopping, like an
object dump or stack
trace or something.



When a program dies abnormally on the iSeries (for ILE/C) you don't
get a core dump as such, what you get is either a nice CPF/MCH error
message in the job log or on the status line.



_______________________________________________ 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:
Replies:

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.