Hi, Initially, I use ipcBeginProcess to run the command shown in the bottom using batch mode like the following
icms -nocdsinit -nograph -noblink < /home/irdc/users/wtjong/projects/MSD/shawn/fxdac260/ftc_porting.il
But it doesn't work most of time and the same thing happens using the GUI mode via CIW. Therefore, I remember that from some post, if I don't talk to the process, then just use csh, system, etc. So, I do that and it works perfectly as I expect. But I don't understand why and it is very difficult to trace down the problem because ipcReadProcess(cid) shows nothing at all. Anyone knows how to trace down this problem or any clue to do so? I don't know if I have luck next time if I need to use ipcBeginProcess. Thanks.
sprintf(info_str "/home/irdc/users/wtjong/work/designkit/optimization/utility/msd2.new/libChar/post_sim_find %s" fc)
;cid = ipcBeginProcess(info_str);
Best Regards, Wells Jong
What release are you on? Have you reported this to Cadence Support?
In reply to Austin CAD Guy:
The other thing I wondered about was whether the program you are launching takes some time to run, and doesn't flush its buffers. Typically (unless you do something about it), most programs use stdio and have buffered output - so nothing actually appears until you have a buffer's worth (usually 1K bytes). When the program finishes, the buffers will get flushed, but sometimes if you have some kind of interactive back-and-forth between two apps, you need to force the buffers to be flushed (how you do that depends on the language you've written the spawned application in).
Of course, it may be something completely different - but you didn't give much info.
Ted's right though - it probably makes sense to report this to customer support and work through it that way.
In reply to Andrew Beckett:
Thanks for the hint. The outside program, a C program, takes input from the SKILL program through the file IO and the SKILL program doesn't need its output. So, the program it's like
for( task all_task
increase the file_name_counter
prepare the file for the C program, the name is file_name_counter ;; this is another problem I can not quite
;; explain, if the name is the same then the
;; following ipcBeginProcess will break at the
;; second time, and from the message of
;; ipcReadProcess, it is said that the C program
;; complains the input file is missing. After
;; several try, I found this problem gone
;; if the input file name is different at each time.
ipcBeginProcess("run the C program with file_name_counter") ;;
BTW, since to run the C program requires some environment setting, therefore to use ipcBeginProcess, I create a csh script there and test it through CIW by tying
ipcBeginProcess("run the C program with file_name_counter")
Everthing is quite okay. So, I use "load the_skill_code" in the CIW and it seems good, too. But, when I do it on batch mode, this strange thing shows up. I have tried to put some check points in the csh script like the following
echo "check point 1" >> error_log
## some csh commands
echo "check point 2" >> error_log
run the c program
echo "check point 3" >> error_log
Sometimes, only check point 1 appears in the erro_log, sometimes, check point 2. Very strange, then I went back to CIW and found that this problem occasionly appears! Eventually, I found that "system" can do this task and the testing result is very stable. I didn't see this happening again. But I wonder what the problem is and like to see if anyone can help to resolve this weird thing. Thanks a lot.
In reply to WellsJong:
Unfortunately I think too many of the details are missing to know what the problem really is. If the program is complaining about the input file being missing, that's not really anything to do with ipcBeginProcess.
Your script also has "set LD_LIBRARY_PATH=..." - I presume if it's a csh script, then it should be "setenv LD_LIBRARY_PATH ..." (i.e. setenv not set, and no "=").
Unfortunately there's too little specific information in your description to be able to diagnose anything.
The best thing would still be to report this to customer support, even though you have a workaround in place. I'm not convinced it's really a problem with ipcBeginProcess though...