Optional arguments on subprocedures

The prototype for an API to retrieve the contents of a data area is defined like this: d apirtvdta_ pr 2559 varying d name 10 const d lib 10 const d opt_start 4b 0 const options(*nopass) d opt_length 4b 0 const options(*nopass) The execution is coded as: c eval apirtvdta = apirtvdta_(name:lib) The first call works successfully, but subsequent calls indicate that the optional parameters have been given addresses at some point even though the first call showed the addresses as *NULL. I have put the subprocedure into debug mode (it is in a service program) and the addresses are still null as of RETURN. Any ideas?

Answer Wiki

Thanks. We'll let you know when a new response is added.

if %addr(opt_start) <> *null;
is for options(*omit)

checking *nopass is done with
if %parms >= 3;
begin=opt_start; …

Discuss This Question: 1  Reply

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TomLiotta
    Since you have given us no idea what the procedure interface for apirtvdta_() looks like nor what apirtvdta_() does with its arguments, we can only guess. My first guess would be that there is a parameter mismatch for apirtvdta_(). And a guess where the mismatch is is for opt_start and/or opt_length. The first oddity is that both of those are declared as 4B 0 which is a very poor choice. Unless these are database fields, it's almost a guarantee that 'B' is a wrong choice. But that's only a 'first guess' because it's so common and because the 'B' data type probably shouldn't be there. What might be more likely is that there are other procedure calls in the program that have three and/or four parameters. The fact that you have *NOPASS parms doesn't mean that there "will not be" any address pointers in those positions. It means that your call won't be putting address pointers there. JPLamontre's answer comes from that thought. You can't test for *NOPASS simply by checking to see if there is a null pointer there. There might be a null pointer, or a resolved pointer or completely random bytes. Since you didn't pass anything, you have no way to know what might or might not be there. If some previous procedure call built a parm list with valid pointers in the third and/or fourth positions, the parm list memory probably hasn't changed. So, you need to check the actual count of parms. Don't access anything in the parm list beyond the number of parms that was passed. Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: