×
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.
Hello,
Understand, I normally prefer to use OPDESC to figure out the length
when possible. Why make all the callers do the work when there is a way
to figure it out internally ;).
I'm trying to understand the scenario... I'm envisioning that you
have multiple "exported" procedures available to the caller, and all
need to call an "internal" procedure and pass this data on to the
internal procedure.
The problem is, when you call the internal procedure, RPG populates the
OPDESC with what THAT PROCEDURE knows about the variable instead of what
the caller provided in it's opdesc. So if you have a 32k VARYING, it
passes 32k as the length, even if the caller only told you it was 4k.
(For example)
So... why use an OPDESC when calling the internal procedure? Why not
retrieve the length in the caller, and pass it as a parameter to the
internal procedure? Since that procedure is never called directly from
the outside, there's no extra effort required by the caller. The extra
effort is only required internally...
The alternative (and the way I usually do stuff like this) is to use a
VARYING string. Then RPG passes the length in the first two bytes of
the string itself. If you want callers to be able to pass a non-varying
string, use CONST on the parameter, and RPG will automatically transform
it to a VARYING and automatically set the length appropriately.
The disadvantage is that you can't use that for RETURNED values. For
returned values, I'd use the OPDESC approach instead, as outlined above.
Unfortunately, that also means you need multiple front-ends if you
want to support both fixed-length and VARYING...
midrange.com
