Re: how to create a command to accept a parm of any length

I had originally composed a reply to the earlier message combining discussion of both RNTVAL(*YES) and RTNVAL(*NO), but decided to just concentrate on the latter and /pretend/ I could not infer what was meant by the "forces me to pass a parm of length 500". I did that because combining the two possibilities [input-only and input-output parameters] into one message got much longer and messier.

So basically I showed only the input-only parameter for simplicity.

Thus... trying to use my command source for defining an input\output parameter will give the error message CPD0784 "Variable &P50 for parameter CHAR500 must be *CHAR, minimum length 500." when compiling the test program; similarly for using the variable &P250. That is almost surely what was implied by "forces me to".

The software in the linked story uses a /trick/ of declaring the smallest possible *CHAR [i.e. LEN(1)] for the command parameter definition, for the parameter defined with the RNTVAL(*YES). There are two *extremely important* things to keep in mind when using that trick; the sources given in the story properly effects both:

1- the validation of the size of the input character variable absolutely *must be performed before* setting a value into the return variable.

2- almost as important is that the assignment should be made to the %sst(&rtnvar 3 &inoutLen), where &inoutLen is less than or equal to the varying length provided as input on the passed &rtnvar, versus using an assignment made to the &rtnvar itself. That is because the &rtnvar can be much larger than the storage allocated in the CL program that invokes the command, and the effects of such an assignment would depend on implementation. That is, while ignoring the Length Value prefix of the declared &rtnvar, if one were to assume that chgvar &rtnvar %sst(&somevar 1 &somelen) would not write more than %sst(&rtnvar 1 &somelen), that would be an assumption. While the safe effect of not writing the entire length of the &rtnvar is most likely true in a CLP, that is not guaranteed, and in other languages [e.g. RPG] the equivalent assignment will often effect blank padding which means blanks would likely overwrite unexpected portions of automatic storage in the invoking program... which could lead to all sorts of problems.

Regards, Chuck

On 16 Apr 2013 14:31, Stone, Joel wrote:

Thanks Chuck. This works perfectly!

I also found the article below.

http://www.itjungle.com/fhg/fhg112906-story01.html

CRPence on Tuesday, April 16, 2013 10:27 AM wrote:

On 15 Apr 2013 14:11, Stone, Joel wrote:

I would like to create a command to accept a parm of any length.

Must I use VARY(*YES) in the CMD source?

Do I then have to check the 1st two bytes of the parm for the
length?

Yes. The number of bytes of the integer length type *INT# that was
specified for Value Length [second element of the VARY()
parameter].

If I state the LEN(500) as the max length, I would like any CL
pgm to use the command with a parm of any length 500 or less.

Normally a program would always declare the same length as the
invoked program to prevent any issues due to parameter length
mismatches. As long as the *VARY parameter is only ever received by
the CPP vs any other CALLable interface, then all can work well.

But the calling pgm forces me to pass a parm of length 500.

Such a restriction was never enforced in older releases. I would
be hesitant to accept that as accurate... without some error
message describing what is meant.

I have tried VARY(*YES), but it seems to not work well.

What is required in addition to VARY(*YES)?

Both "forces" and "not work well" are nebulous. Any concrete
examples? Hopefully my example below will cover what is being
attempted.

Nothing more than VARY(*YES) is required on the *CMD. But then one
must code the CPP to properly handle and use the additional data;
i.e. the declaration in the CPP would be for 502 bytes vs 500, to
accommodate the length value that precedes the character data. And
the CPP should use that Length Value to access only that much of
the passed character data in the field [e.g. via %sst]; i.e.
neither the entire 500-byte component nor the overall 502-bytes of
the full variable should ever be accessed.

Treat the PARM as input-only and look only at the data up to the
length provided, and there should be no difficulties. See the
following example <<SNIP; see the archives>>