Re: Terminating a C proram

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Hello Mike,

You wrote:
>1.     EPM does not exist and  is of no concern to the current C compiler
>and run-time.. This means that the Jennifer Hamilton book is well out of
>date? I couldn't find any mention of Activation Groups in the index, and the
>first (and only!) publishing date was October 1992!!. For $200 Australian I
>would expect that the publishers keep the book up to date. I feel a little
>skinned

If you are truly unhappy then send it back.  I know Intelligent Techologies 
will accept 
returns if you are not happy with the book.  I think Midrange Computing will 
also.  I 
don't know which one you purchased from but if it were me I'd send it back.  It 
should 
only cost you the freight charges.


=============== stuff deleted =============================             

>3.     I looked up the ILE C Programmers Guide(appendixH) where it
>states.....keeping an activation group active after the program has exited
>means that all the storage associated with that program is still allocated
>and in a 'last-used' state. When the program is called again,
>initialization, as defined by the language, is not done. All variables have
>the last value assigned to them in the previous run of he program. In
>addition all of the settings in the ILE C run-time are in 'last-used' state
>such as signal(),strtok() etc......." .(reference H1.1).

Interesting, I would expect automatic storage to be reinitialised regardless of 
activation group persistence.  Ah, I think I see ... the test code is issuing a 
return 
from main() rather than the more usual exit().

Since most RPG programs have no concept of automatic storage, using return 
should result 
in behaviour similar to that expected by an RPG programmer.

>       ..............no mention of the static attribute............
>
>       In the same section they provide some example code and so I  created
>two C programs (copied from H1-1 in the users guide), one called TESTRTRN
>(with a return;) and the other TESTEXIT(with the return replaced by an
>exit() with test harnesses as follows:

=============== stuff deleted =======================
                        
>       TEST 2 worked as I wanted. The value of I was retained between
>invocations for the TESTRTRN program The TESTEXIT program also worked
>correctly with I being output as 1 on each call.
>       TEST 1 printed I=1 each time it was called. Correct for the TESTEXIT
>program but not for the TESTRTRN program.

>       I thought perhaps that *NEW and named would work in the same way but
>unfortunately no! I'm still unsure about the difference. More manual bashing
>I think.

*NEW activation groups are created by the system on invocation and destroyed by 
the 
system when the program terminates.  Named activation groups are created on the 
first 
call to a program using that activation group and are not destroyed until 
either the job 
ends or an explicit termination of the activation group occurs.  C (well CRTPGM 
really) 
creates programs using *NEW activation groups by default, even though that is a 
good way 
to kill performance, because doing so makes the program comply with ANSI C 
semantics.  
The nett result is that all storage is initialised because no storage remains 
from 
previous invocations.

>       This TEST 2scenario seems like it will solve my problem, as the
>return corresponds to the RPG return, as does the exit() to SETON *INLR as
>long as the activation group is named.


Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| 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
+---