I remember this 32 byte thing often. I still have customers running into
it for the first time in years and having to try explain it (since as
stated email addresses and IFS paths are usually in use now) :)
Just make the field one byte longer, put a character in the last byte, and
substring it when it gets in the CL. Works every time. :)
On Mon, Apr 14, 2014 at 1:04 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>wrote:
I think your original issue was about literals being passed in SBMJOB of
a CALL, correct?
These are related but separate issues, seems to me.
Neither is a bug - I can't see IBM changing anything after 34 years of
this kind of behavior.
I think Buck is right - we forget this in most cases, since we deal with
data that is often shorter than 32 characters - address information,
names, all that.
As soon as we start dealing with email addresses and IFS pathnames and
the like, we get bit!
On 4/14/2014 12:50 PM, Steinmetz, Paul wrote:
Buck,occur pgm to pgm.
I agree with everything you stated, except IBM is stating this can also
of the receiving variable, the receiving procedure or program cannot access
From the V7R1 info center.Character length errors
When you pass character values with incorrect length, errors might occur.
If you pass a character value longer than the declared character length
the excess length. In the following example, PGMB changes the variable that
is passed to it to blanks. Because the variable is declared with LEN(5),
only 5 characters are changed to blanks in PGMB, but the remaining
characters are still part of the value when referred to in PGMA.
PGM /* PGMA */handled this way may function differently than expected.
DCL &A *CHAR 10
CHGVAR &A 'ABCDEFGHIJ'
CALL PGMB PARM(&A) /* PASS to PGMB */
IF (&A *EQ ' ') THEN(...) /* THIS TEST FAILS */
PGM PARM(&A) /* PGMB */
DCL &A *CHAR 5 /* THIS LEN ERROR*/
CHGVAR &A ' ' /* 5 POSITIONS ONLY; OTHERS UNAFFECTED */
While this kind of error does not cause an escape message, variables
declared length in the receiving procedure or program, there may be more
If the value passed to a procedure or program is shorter than its
serious consequences. In this case, the value of the variable in the called
procedure or program consists of its values as originally passed, and
whatever follows that value in storage, up to the length declared in the
called procedure or program. The content of this adopted storage cannot be
predicted. If the passed value is a variable, it could be followed by other
variables or by internal control structures for the procedure or program.
If the passed value is a constant, it could be followed in storage by other
constants passed on the CALL or CALLPRC command or by internal control
the original value and on the adopted storage. The immediate effect of this
If the receiving procedure or program changes the value, it operates on
could be to change other variables or constants, or to change internal
structures in such a way that the procedure or program fails. Changes to
the adopted storage take effect immediately.
called program. Character constants are passed with a minimum of 32
In the following example, two 3-character constants are passed to the
characters for the Call (CALL) command. (Normally, the value is passed as 3
characters left-adjusted with trailing blanks.) If the receiving program
declares the receiving variable to be longer than 32 positions the extra
positions use adopted storage of unknown value. For this example, assume
that the two constants are adjacent in storage.
CALL PGMA ('ABC' 'DEF') /* PASSING PROG */called procedure. Only the number of characters specified are passed for
PGM PARM(&A &B) /* PGMA */
DCL &A *CHAR 50 /* VALUE:ABC+29' '+DEF+15' ' */
DCL &B *CHAR 10 /* VALUE:DEF+7' ' */
CHGVAR VAR(&A) (' ') /* THIS ALSO BLANKS &B */
Values passed as variables behave in exactly the same way.
In the following example, two 3-character constants are passed to the
the Call Procedure (CALLPRC) command. If the receiving program declares the
receiving variable to be longer than the length of the passed constant, the
extra positions use adopted storage of unknown value.
In the following example, assume the two constants are adjacent in
CALLPRC PRCA ('ABC' 'DEF') /* PASSING PROG */midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
PGM PARM(&A &B) /* *PRCA */
DCL &A *CHAR 5 /* VALUE:'ABC' + 'DE' */
DCL &B *CHAR 3 /* VALUE:'DEF' */
CHGVAR &A ' ' /* This also blanks the first two bytes of &B */
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
Sent: Monday, April 14, 2014 12:09 PMgettinggarbagewhencalled from AJS
Subject: Re: CLP pgm with 2 paramters intermittently
make a CMD instead of doing a CALL, then this 32 byte issue goes away?
On 4/11/2014 10:04 PM, Steinmetz, Paul wrote:
From previous info in this thread, is it still correct that if you
Yes.characters between two CL programs requires special handling.
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
pgm to pgm.
IBM confirmed this is not only from a command line, but can also occur
only an issue on programs trying to pass literals instead of variables.
can also occur pgm to pgm.I strenuously disagree with this as stated. The 32 character default is
If you think about it, the command line has no provision for defininga variable, so we can only specify a literal on the command line (or
the calling program 1 byte longer than the parameter in the called program.
As a workaround, IBM is actually suggesting to make the parameter in
Again, this is only if you need to pass a 33+ character literal whichends in blanks.
the issue, however, not finding any documentation to confirm/support this.
IBM also confirmed that using a CMD instead of a call should not have
The reason a CMD works is that the command language allows one to definethe length and type of each parameter - even parameters which appear to be
passing a literal value.
program that has a call with a parameter defined with a length of 32 bytes
Question, is there a source search I could perform that would find any
If there is a parameter defined in the calling program, there is noissue. It is only if the calling program is passing a literal that you
need to be concerned about the default buffer size.
parameter longer than 32 bytes AND ALSO is called by a program which passes
So really what you're looking for is any program that receives a
a literal instead of a variable AND ALSO the calling program's literal is
shorter than 33 bytes.
buffer rule off the top of their head :-)
This situation is rare enough that few people remember this 32 byte
--bucklist To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-lmoment to review the archives at http://archive.midrange.com/midrange-l.
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives