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') */
midrange.com
