On 4/11/2014 10:04 PM, Steinmetz, Paul wrote:
From previous info in this thread, is it still correct that if you make a CMD instead of doing a CALL, then this 32 byte issue goes away?
CALL is a CMD, so why would other commands be treated differently?
CALL is not the problem. The command line (usually) is.
Also, I opened PMR with IBM to confirm the 32 byte issue, using CALL or CMD
IBM has a doc. Passing parameters that are longer that 32 characters between two CL programs requires special handling.
IBM confirmed this is not only from a command line, but can also occur pgm to pgm.
can also occur pgm to pgm.
I strenuously disagree with this as stated. The 32 character default is
only an issue on programs trying to pass literals instead of variables.
If you think about it, the command line has no provision for defining a
variable, so we can only specify a literal on the command line (or SBMJOB).
As a workaround, IBM is actually suggesting to make the parameter in the calling program 1 byte longer than the parameter in the called program.
Again, this is only if you need to pass a 33+ character literal which
ends in blanks.
IBM also confirmed that using a CMD instead of a call should not have the issue, however, not finding any documentation to confirm/support this.
The reason a CMD works is that the command language allows one to define
the length and type of each parameter - even parameters which appear to
be passing a literal value.
Question, is there a source search I could perform that would find any program that has a call with a parameter defined with a length of 32 bytes or more.
If there is a parameter defined in the calling program, there is no
issue. It is only if the calling program is passing a literal that you
need to be concerned about the default buffer size.
So really what you're looking for is any program that receives a
parameter longer than 32 bytes AND ALSO is called by a program which
passes a literal instead of a variable AND ALSO the calling program's
literal is shorter than 33 bytes.
This situation is rare enough that few people remember this 32 byte
buffer rule off the top of their head :-)