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 ADVANCED SYSTEMS CONCEPTS |
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 . |