|
Simon, nice summary. Mike doesn't want to use EPM but you didn't come right out and say that. Mike, don't even think about EPM, it will make you crazy - but very very slowly. There are a few more historical fragments - like the fact that EMP was not originally built to be sold, it was supposed to be a demonstration. System/C was suggested to one of the AS/400 system architects by some meathead. I think it was at the Fall of 1988 Common meeting. The Modula compiler was originally used to rewrite some of the PL/MI into OO forms and was never released, C was used instead. The stack handling in EPM did not use the MI instructions created to do stack handling - they were too slow. The EPM environment was originally created for Pascal on the 38. blah blah blah. Richard Jackson mailto:richardjackson@richardjackson.net www.richardjacksonltd.com Voice: 1 (303) 808-8058 Fax: 1 (303) 663-4325 -----Original Message----- From: owner-c400-l@midrange.com [mailto:owner-c400-l@midrange.com]On Behalf Of Simon Coulter Sent: Tuesday, August 08, 2000 7:09 AM To: C400-L@midrange.com Subject: Re: Terminating a C Program Hello Mike, You wrote: >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.. C doesn't have that concept. The closest you can come is by declaring static variables and using a named activation group. I haven't tried it but since named activation groups persist until explicitly destroyed and static variables maintain state over invocations the nett result should be the same. Exactly what are you trying to acheive? >I'm also bit confused as to which program model I have when I compile my C >program C programs since VRM230 are ILE programs. Prior to that they were EPM or System/C. >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. These commands refer to the EPM environment which was a stepping stone on the way to ILE. It added multiple entry points, binding, and long names to the system but since it was imposed over the standard program model it also had a major performance impact -- most noticable when starting the environment or invoking the first EPM program. >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? You don't have any choice. EPM programs can no longer be created although I think they will still run (certainly on Version 3, and possibly on Version 4). Query Management was written in Modula-2 which was an EPM compiler and I don't think it has been converted so that would suggest the runtime support is still present. >I've have looked at the C Programmers Guide, but to no avail. The C manuals relate to the current ILE dialect. There used to be an appendix discussing migrating from EPM C to ILE C but it may have been removed. >Any help out there? Well, that really rather depends doesn't it? :) 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 +--- +--- | 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 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.