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


  • Subject: Re: Terminating a C Program
  • From: "Jevgeni Astanovski" <jevgeni@xxxxxxxxx>
  • Date: Tue, 8 Aug 2000 09:13:19 +0200 (EET)

> From:          "Pantzopoulos, Mike" <mikepantzopoulos@mynd.com>
> To:            "'C400-L@midrange.com'" <C400-L@midrange.com>
> Subject:       Terminating a C Program
> Date:          Tue, 8 Aug 2000 01:40:08 -0400 
> Reply-to:      C400-L@midrange.com

Mike,
I hope someone with more experience and understanding of C/400 will 
give you a better answer. I'll just share my experience.
First the easiest issue. About program model. If you are talking 
about small/medium/large - this is a pure INTEL staff. I have not 
found something similar in C/400.
Second: acting as RPG. It is not quite clear what you are talking 
about, but C-programs I write are actually our 
third-party application's API-s, and its native API manager does not 
even know, that these are not his native RPG programs.
My API-s return variable amount of data thus to gain a result 
sometimes it must be called several times. And it must know where is 
the first call and where is continuation. I personally do not use 
this practice, but there is a good evidence, that via the mechanism 
of activation groups most of internal variables stay intact between 
the calls. Some of my friends said that they use this technique and 
even if a file is opened (_Ropen) in a first call and say ten records 
are read and file is not closed, then in a second call, if you do not 
open the file, your first _Rreadn will read the next record (number 
11). Once again, I do not use this practice, but at a first glance 
there is a bunch of problems. In the case above how do you know that 
the file is already open? Then still the program MUST know, whether 
it is the first call or the next.

> I have a few problems in understanding the program model that is used for C
> programs, and how the C program acts in the stack when called from RPG. 
> In essence I want the C program to behave like an RPG program - ie it stays
> resident until *INLR is set on. Is there a way of doing this in C?
> Alternatively, how do I control the invocation and termination of a C
> program ? My current C program is terminating each time it returns, and I
> need it and it's lower level RPG invocations to stay resident until I'm
> ready to end them.. 
> 
> I'm also  bit confused as to which program model I have when I compile my C
> program 
> 
> In my travels through Jennifer Hamilton's book, I saw a reference to
> STREPMENV and ENDEPMENV and I thought this might be the answer to the above
> problems. 
> Unfortunately, it turns out I have ILE C program created using the CRTBNDC.
> When I look at the DSPPGM output, I find that this is an ILE program. When I
> use CRTCMOD/CRTPGM, of course it's an ILE program. I shouldn't have to
> create an EPM program should I? 
No, you should not.
HTH, and hope that someone will provide deeper answer.
I'd read read it with pleasure.....

Regards,
Eugene Astanovsky
+---
| This is the C/400 Mailing List!
| To submit a new message, send your mail to C400-L@midrange.com.
| To subscribe to this list send email to C400-L-SUB@midrange.com.
| To unsubscribe from this list send email to C400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: bob@cstoneindy.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.