RE: Dumb question(s) -- MIDRANGE-L

Sudha Ramanujan wrote:

> I must be doing all wrong.

If I understand what you're saying, then I'm rather afraid you are ;-).

> I wrote a C function char *FOUNDDIR(char *fn) to return a
> string (pointer to a string) and compiled it as a service
> program using CRTSRVPGM SRVPGM(sudsrvpgm) EXPORT(*ALL)
> SRCFILE(c_src) BNDDIR(SUDBNDDIR).

This looks like you are trying to create a service program directly from
a C source member.  A service program is made up of modules and
(optionally) links to other service programs.  So your first step is to
create the module.

>  CRTCMOD MODULE(sudsrvpgm) SRCFILE(C_Src) OUTPUT(*print)
> OPTION(*SHOWSRC
>  *SHOWUSR) DBGVIEW(*ALL) SYSIFCOPT(*IFSIO *IFS64IO)

That's probably correct (I don't do much C).  I'm not sure about
SYSIFCOPT and there's _no help for it_ on our V5R1 box -- an IBM rarity.

Once the module is created you'll want to bind it into your service
program.  This is where we have to think about CRTSRVPGM's SRCFILE
parameter.  It's not for your C source, as you used above, but for
something called binder language source.  Binder language is quite
simple, and it defines the procedures (and data, if any) that your
service program exports.  However, to keep it simple I'll leave its
details as an exercise to the reader (check the archives, among other
places) and we'll just export all procedures:

CRTSRVPGM SRVPGM(sudsrvpgm) EXPORT(*ALL)

I think will do it, since your module has the same name as your service
program.  Incidentally, I'm surprised your CRTSRVPGM above worked: I
thought EXPORT(*ALL) and SRCFILE(anything) were mutually exclusive; but
that's neither here nor there.

> I then called this service program from my rpgle as follows.

This reflects a common misconception (or misuse of terminology):  you
don't call a service program.  You call a procedure which may or may not
be contained in (and exported from) a service program.

>
> d founddir        pr              *
> d  dir                            *    value options(*string)
>
> d ptr              s              *
> d rtnstr           s           20     based(ptr)
>
> c                 ptr = founddir('/')
> c                 dsplay           rtnstr
>
> The rtnstr is a junk value.  ptr is a regular pointer value.
>  I also tried
>
> d founddir        pr           20
> d  dir                            *    value options(*string)

I think the first prototype is correct, since the C function returns a
pointer.  I'm not sure how you were able to run it at all, though,
because (assuming I am understanding your post correctly) the module
containing the C procedure didn't exist, therefore nothing was exporting
the procedure; I don't understand how your RPG program compiled (the RPG
module, yes, but I'd expect program creation to fail at bind time).  So
maybe I've got it all wrong ;-).

Anyway, if you do all this and then start debug, and add your service
program to your debug environment, you _should_ see your C code in the
debugger.

HTH.

Cheers,

Martin.

--
Martin McCallion
Senior Technical Consultant
Work:  martin.mccallion@misys.com
Home: martin.mccallion@ukonline.co.uk
Misys International Banking Systems
1 St George's Road, London, SW19 4DR, UK
T +44 (0)20 8486 1951
F +44 (0) 20 8947 3373
www.misys.com
This email message is intended for the named recipient only. It may be
privileged and/or confidential. If you are not the  intended named
recipient of this email then you should not  copy it or use it for any
purpose, nor disclose its contents to any other person. You should
contact Misys International Banking Systems as shown below so that we
can take appropriate action at no cost to yourself.
Misys International Banking Systems Ltd,1 St
George's Road, London, SW19 4DR, UK. Email: ibs.postmaster@misys.com.
Tel: +44 (0) 20 8879 1188 Fax: +44 (0) 20 8947 3373
Misys International Banking Systems Ltd is
registered in England and Wales under company no. 971479