• Subject: Re: API parameter lengths
  • From: "Larry Loen" <lwloen@xxxxxxxxxx>
  • Date: Wed, 11 Jul 2001 15:56:01 -0500
  • Importance: Normal


Steve Richter wrote:

   on a windows pc this is also not an issue because pgms dont
   call other pgms like they do on the 400.  The pgm call
   equivalent in Windows is a call to a function in a dll.

Quite right.  But, of course, a DLL is very analogous to our *SRVPGM.

   So Larry, does the C pgm make a copy of the string before
   it null terminates it?

I would expect it does.  Remember that to follow the C conventions, the
"first" parameter (argv[0] in C terms) is the name of the program, so a
copy is likely anyway since the second parm on main is an array of arrays.
This would be most unlikely to match the original OS/400 calling
conventions, which is a series of strings and, possibly, even decimal
numbers

   And weather(?) a copy is made or not, does the C pgm know the size of
   the
   data passed?

I should have not jumped in while still jet-lagged.  I'm having trouble
remembering my name much less all these details today.  Still, this is why
I think this is part of why I mentioned (in passing) the command processor.
It seems to understand some of these things.  I would suggest some simple
experiments, especially with a series of calls from the same command line
(so that it is likely the previous data would be used at least before the C
program was invoked).  A series of calls like:

CALL  TEST  '12345' '212345'
CALL  TEST  '124' '214'
CALL  TEST  '123 45'  '2123 46'

and see what happens to an ordinary "printf" of the first two parameters.
Do the same thing wrappering TEST in a command that describes a fixed
length string for each parameter.  Try bigger string to smaller and back
again would be the thing I would try.  I presume that using CALL means
someone somehow infers the size from the distance between quotes, but how
that is copied is not clear to me (not without coding it up myself to
remind myself of all these little details).  As I've said, the command line
processing may be a bit different, if for no other reason that I believe if
you describe the parameters sufficiently well, that incoming strings can
get padded with space characters and so on, which eliminates a few of the
more odd-ball things that have happened to me now and then when I use a
series of ordinary CALL statements carelessly.  But, my memory fails me on
exactly what happens.

   Also, do as400 C pgms return values to the caller?

I believe *SRVPGMs would and could return whatever they are defined to
return.  The implications of returning character strings to compiled ILE CL
is a bit beyond me today (I recall there are some interesting conventions
on the CL side of it, but I don't use them, so I don't know).  This should
be documented in the various manuals, however.  The return 0 or return n
statement for some 32 bit integer n would be, I think, what main (by
standard convention) returns to OS/400 and this should be have "normally."

Normally, I would code these up and put in the results myself, but I'm not
up to that today.  Try a few experiments. . .



Larry W. Loen  -   Senior Java and iSeries Performance Analyst
                          Dept HP4, Rochester MN

Speaking on his own. . .


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---

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