On 13/06/2008, at 11:48 PM, Lim Hock-Chai wrote:

Thanks Barbara. I simplified my function to make it easier for me to
ask the question. The actual function prototype looks like below:

typedef char *logECD_STP3_piModuleName_T;
typedef char *logECD_STP3_piLocationID_T;
typedef char *logECD_STP3_piLogMessage_T;
typedef int logECD_STP3_piByteRcv_T;
typedef char *logECD_STP3_piDataRcv_T;
decimal(15,0) logECD_STP3(
logECD_STP3_piModuleName_T moduleName,
logECD_STP3_piLocationID_T locationID,
logECD_STP3_piLogMessage_T logMessage,
const logECD_STP3_piByteRcv_T *byteRcv,
const logECD_STP3_piDataRcv_T *dataRcv);

If you're simply using typedef to provide names for char* then I wouldn't bother. Your original approach of using typedef to describe fixed-length data values is better although weird from a C programmer's perspective because the language (and therefore most C programmers) has no concept of fixed-length variables. AT least with the structures there is a length involved whereas char* has no length.

logECDSTP3 is actually a RPG export procedure and the RPG prototype for
logECD_STP3 looks like below:
P logECD_STP3...
P B export
D pi 15 0
D piModuleName * options(*string) value

D piLocationID * options(*string) value

D piLogMessage * options(*string) value

D piByteRcv 10i 0 options(*nopass :*omit) const

D piDataRcv * options(*nopass :*omit)
D const

The c program is casting the UAM (<= Data from recv()) and passing it to
the 5th parameter of logECD_STP3. The 4th parameter tell logECD_STP3
how long the 5th parameter is.

C passes everything except arrays by VALUE. RPG defaults to passing everything by REFERENCE. Embed in your mind the following mantra:

Passing a pointer by VALUE is the same as passing a variable by REFERENCE.

Therefore you can have a C prototype that passes pointers (addresses) into an RPG prototype that accepts fixed-length variables. For example:

void rpgProc( const char * msgId );

char * msgId = "CPF1234"; /* char msgId[7] works too as long as you strip 0x00*/
rpgProc( msgId );

D rpgProc PI
D msgId 7 CONST

c is really fun.

You have a strange idea of fun :)

It is not very programmer friendly language though.

No it's not. It's basically a high-level assembler. It requires the programmer to play compiler while writing code (to avoid stupidities) rather than concentrating on the task at hand. C itself is fairly useless--it is is the library functions that make it useful. See how far you get writing a program if you have no #include statements for stdlib.h, stdio.h, string.h, etc.

As someone else noted C is perhaps the only mainstream programming language where a successful compile is no indication the program will even run. At least with COBOL, RPG, PL/1, Java, Smalltalk, Basic, etc. as long as you are a competent programmer with a reasonably clear idea of what you want to do a successful compile indicates your program will do at least 80% of what you intended.

Not sure how this language can be so successful till this day. :)

Three primary reasons:
1) Because it was given away free to Universities
2) Because it supported advanced (for it's time) concepts such as local variables, functions/procedures, prototyping, etc. Useful when teaching programming.
3) Because people stick with what they know. For most programmers C is the first "real" language they learn. CompSci courses spend a lot more time on C than other languages. If C is the first language you learn you think it's fine because you don't know any better. Once a language reaches a certain critical mass it's hard to avoid it simply because there is such a large code base in use.

C is fine for low-level systems code--it's rubbish for business applications.

Simon Coulter.
FlyByNight Software OS/400, i5/OS Technical Specialists

Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
ASCII Ribbon campaign against HTML E-Mail / \

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.