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?

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your response...

Discuss This Question: 1 &nbspReply

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

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

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

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

To follow this tag...

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy