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



Thanks simon, plenty for me to go on there... but looking at all the options
in qsysinc/mih matmatr - is there any documentation on the subfield values?
I'm just looking at v4r3 books and cant find a match.

Thanks...

> -----Original Message-----
> From: owner-c400-l@midrange.com [mailto:owner-c400-l@midrange.com]On
> Behalf Of Simon Coulter
> Sent: 05 January 2001 21:04
> To: C400-L@midrange.com
> Subject: Re: c to rpg
>
>
> 
> Hello Brendan,
>
> You wrote:
> >Im using the MATMATR example to retrieve the serial number, but I dont
> >understand how C returns parameters (to my RPG module):
>
> It doesn't return parameters naturally.  A C main expects to
> return an integer
> (or possibly void but that's usually poor form) so you need to force C to
> behave the way you want.
>
> Note that you can use the MI functions directly from ILE RPG if
> you wish --
> see below.
>
> >The C program has int main(void) {
>
> Which tells C that no arguments are being received so you have to
> change the
> signature.
>
> >I know I can access incoming arguments with arg[] but how do I return the
> >serial number (and anything else) as a parm... I think I have to
> replace the
> >"void" with one or more parms
>
> The only interface to main() that can be specified is one of:
>       main(void)
> or
>       main( int argc, char * argv[])
>
> so you have to work within the restrictions of the language.  C
> expects an
> array of pointers to be passed.  The first element always points
> to the name
> of the program, the second element is the first of the caller's
> parameters,
> and so on.
>
> Recall that C passes everything by value and expects things
> passed by value.
> Since passing a pointer by value is the same as passing a variable by
> reference, the pointer received by C in the second element addresses the
> storage allocated by our caller.  All the C program needs to know
> is how to
> view that storage.  The view of storage is handled nicely by real
> compilers
> (assuming the definitions in the caller and callee are the same) but C
> requires you to "know" what was passed and copy the appropriate
> bytes into
> your callers storage manually.  Here is an example C program
> (TSTMATMATC) that
> does what you want:
>
> #include <matmatr.mih>
> #include <string.h>
>  _MMTR_Template_T    machine_attributes;
>  int main(int argc, char * argv[])
>

>     machine_attributes.Options.Template_Size = 16;
>     matmatr( &machine_attributes,  _MMTR_SERIAL );
>     memcpy((void*)argv[1],
>              machine_attributes.Options.Data.Serial,
>              sizeof(machine_attributes.Options.Data.Serial) );
>   }
>
> call it using the following test harness:
>
> pgm
> dcl &serial *char 8
>
> call tstmatmatc (&serial)
>
> sndpgmmsg msg('Serial number:' *BCAT &serial)
>
> endpgm
>
> and here is an RPG IV version of the original C example program which is
> probably more suitable (and certainly easier to modify):
>
> H BNDDIR('QC2LE') DFTACTGRP(*NO) ACTGRP(*CALLER)
>
>
>
> D machineAttributes...
>
> D                 DS                  INZ
>
> D   MMTR_Template_Size...
>
> D                               10I 0
>
> D   MMTR_Bytes_Used...
>
> D                               10I 0
>
> D   MMTR_Serial...
>
> D                                8
>
>
>
> D $MMTR_SERIAL_   S              5I 0 INZ(4)
>
>
>
> D matmatr         PR                 EXTPROC('matmatr')
>
> D   attributes                    *   VALUE
>
> D   attrLen                      5I 0 VALUE
>
>
>
> C                   EVAL      MMTR_Template_Size =
> %SIZE(machineAttributes)
> C                   CALLP     matmatr( %ADDR(machineAttributes) :
>
> C                                      $MMTR_SERIAL_ )
>
>
>
> C     MMTR_Serial   DSPLY
>
>
> C                   SETON                                        LR
> C                   RETURN
>
>
> 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 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.