×
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.
On 6/20/2013 3:45 PM, Booth Martin wrote:
Oh gosh. I checked that with the DSPLY line of code and got the results
I expected. I did get "DSPLY No Parm" when I called the program with no
parm passed.
I don't doubt your comment; after all, why would IBM create *NOPASS if
it is ignored? In other words, more confusion for me at the elementary
level.
Hi Booth, watch out for *NOPASS (also *OMIT and *VARSIZE). There be
tygers. (I really wish we had used a different keyword for the "do
something nice for me" options vs the "let me break the rules" options.
But we didn't, so you have to learn which ones are always safe to use,
and which ones need special care in the procedure.)
Here's a paragraph from the doc for the OPTIONS parameter,
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasd/sc092508550.htm#doptns.
"Note:
For the parameter passing options *NOPASS, *OMIT, and *VARSIZE, it is up
to the programmer of the procedure to ensure that these options are
handled. For example, if OPTIONS(*NOPASS) is coded and you choose to
pass the parameter, the procedure must check that the parameter was
passed before it accesses it. The compiler will not do any checking for
this."
Errr ... I think it means to say "if you choose _not_ to pass the
parameter" ...
Basically, those three options tell the compiler to let your callers
break one of the rules for parameter-passing safety. *NOPASS lets your
callers pass fewer parameters, so your procedure has to take care of
that. *OMIT lets your callers pass a place-holder, *OMIT, so your
procedure has to take care of that. *VARSIZE lets your callers pass
too-short parameters, so your procedure has to take care of that.
The other options, *TRIM, *RIGHTADJ, *NULLIND, just make it easier to
call your procedure. Your procedure doesn't have to do anything special.
*STRING falls into the last category too, except that your procedure has
to know that it has a null-terminated string. But *STRING is usually
only used for calling APIs anyway.
midrange.com
