String Parameters of Various Lengths, Take Three
June 14, 2002 Timothy Prickett Morgan
Hey, Ted:
The May 29 Midrange Guru, OS/400 Edition, article, “String Parameters of Various Lengths,” is a great explanation of the CEEDOD API, but I don’t see the point in using the technique in this context. A simple variable-length field used as the parameter is far more flexible and avoids the overhead of operational descriptors
![]() |
and the extra API call. Use of the CONST keyword allows you to pass fields of different lengths and non-varying-length fields as parameters, and you can use the %LEN function in the subprocedure to find the length of the string field. Am I missing something?
— Jon Paris
Partner400
jon.paris@partner400.com
The only thing you missed, Jon, is a significant piece of information: that the subprocedure modified the string. I failed to include this ‘small’ fact when I worked up the article. Otherwise, passing variable length fields with the CONST keyword provides a much simpler (and to my tastes, a better) solution.
Here is what the subprocedure would look like if I had been able to use the technique Jon suggests:
H nomain /copy copysrc,myproc P MyProc B Export D PI D String 32767 Const Varying D DataLen s 10i 0 * Retrieve the length of the string parameter C eval DataLen = %Len(String) * Do whatever needs to be done C Return P e
The VARYING keyword tells the RPG compiler that the string value is preceded by a two-byte binary number that indicates the length of the string.
Without the CONST keyword, the compiler will force all callers to define the parameter as variable-length with a maximum length of 32,767 bytes. Adding the CONST keyword relaxes this restriction. The CONST keyword passes a parameter in read-only format and does not require that the passed parameter match the prototype exactly.
A calling procedure can pass a variable-length parameter of a smaller size, a constant, or a fixed-length character variable. The following RPG caller illustrates how data of different types and sizes is passed to the subprocedure:
/copy copysrc,myproc D s1 s 35 varying inz('BR-549') D s2 s 25 inz('I like cheese.') D c3 c const('Mary had a lambchop.') C callp myproc (s1) C callp myproc (s2) C callp myproc (c3) C callp myproc ('Eat at Joe''s')
In the case of a fixed-length variable, the compiler copies the fixed-length variable to a temporary variable-length variable and passes the temporary variable to the subprocedure. The two-byte binary prefix of the parameter contains the length of the fixed-length variable. That is why the %LEN function can be used in the subprocedure to determine the length of the parameter.
CL procedures don’t directly support variable-length data, but that doesn’t mean you can’t use variable-length strings. You can if you’ll handle the mechanics yourself.
Here’s an example:
dcl &s3 *char 45 dcl &sval *char 47 chgvar %bin(&sval 1 2) 45 chgvar %sst(&sval 3 45) &s3 callprc myproc (&sval)
Variable &S3 is to be passed to subprocedure MYPROC. The %BIN (binary) function stuffs the length45into the first two bytes of the parameter &SVAL. The data itself is copied into bytes 3 through 47.
I recommend Jon Paris and Susan Gantner’s article, “The Versatility of Variable-Length Fields,” which you can find at http://eservercomputing.com/iseries/archives/index.asp?a=1&id=146 .
— Ted
Sponsored By![]() |
SEQUEL meets all your iSeries and AS/400 data access needs in a single, integrated solution:
Take 6 minutes to view a SEQUEL ViewPoint ScreenCam movie to see how simple Windows-based AS/400 and iSeries data access can be! In just a few short minutes, you can find out ways to make your job easier and improve data access throughout your organization. Download the ViewPoint movie here . For more information or a FREE trial of SEQUEL, call 847/605-1311 or visit Advanced Systems Concepts . |