Re: manipulating parms

On 12-Feb-2014 08:50 -0800, Mark S Waterbury wrote:

On 2/12/2014 11:17 AM, jmurfitt@xxxxxxxxxx wrote:

I need an easy way to convert parms passed by a CL program from
ALL uppercase to mixed? Keep 2 things in mind, I am not a
programmer although I can write simple programs and also this is an
example of what I need to do. Convert PARMS26 to Parms26.

If you just enclose the values in single quotes, in CL, they will be
compiled and passed "as is" and not be translated to all uppercase.
For example, if you have something like:

CALL PGM(*LIBL/PGMNAME) PARM(Parms26)

the CL compiler will translate the "value" of "Parms26" to "PARMS26"
at compile-time.

But, if the same statement is coded as:

CALL PGM(*LIBL/PGMNAME) PARM('Parms26')

then the CL compiler will leave the value "Parms26" alone and it
will be passed correctly.

If you prompt the CALL command in SEU, you can see when this
happens, so you will know when you need to insert single quotes.

Hope that helps,

FWiW, to elucidate an aspect...

The effect of the upper-casing [AKA folding to upper] of the undelimited character string is seen when prompted due to what the Command Analyzer [which optionally invokes the Command Prompter during run-time] does [according to rules for the parameter]. The compiled listing will suggest that the non-delimited string had *not* been forced to upper case during the compile; somewhat of a lie, but sufficiently accurate output, given the final effect is predictable. The command string actually produced for the executable object however [in contrast to what is shown in the listing], will reflect the effect of the upper-casing, because the command string was formatted by the command analyzer during the compile. That can be seen in a dump or Retrieve CL Source (RTVCLSRC) of the program; either of which shows the command strings, if compile options allow. For example, the following line of CL source will appear identical in the listing, but in the dump or retrieved will appear as the modified version of that same CL request shown as the next line [notice how the parameter keyword gets inserted as well, just as when run after being prompted]:

call pgmname parm(mixedCaseLiteral)

CALL PGM(PGMNAME) PARM(MIXEDCASELITERAL)

For other parameter keyword definitions [i.e. a PARM() defining a parameter of a *CMD object other than CALL], the effect may not be exactly as discussed above [which is specifically about the PARM() of the CL CALL command]. The Command Analyzer may have been instructed by the parameter definition for the command, that the folding to upper is not a desirable effect; e.g. IIRC, as with the PASSWORD() parameter of the CL CHGUSRPRF command. And if the value were to be passed with a variable instead, then the folding effect could only occur at run-time, but when the command analyzer is invoked again at run-time in that scenario, no folding occurs for the value because the value comes from a character string variable rather than from a character string literal. The character string value for a variable used for a prompted parameter would originally maintain the case of that character string value, but the prompting could effect the folding according to the parameter definition, if the user over-types a character or changed a value as an undelimited character string; e.g.:
?CHGOBJD ??TEXT(&p) /* whereby &p started as Parms26 would become PARMS26 when a changed-data was indicated for the input\output area for the TEXT() of the prompted command; if unchanged when prompted, the value for the text would be the same as if delimited: TEXT('Parms26') */