Re: CLP pgm with 2 paramters intermittently gettinggarbagewhencalled from AJS

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. :)

Brad
www.bvstools.com


On Mon, Apr 14, 2014 at 1:04 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>wrote:

Paul

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!

Regards
Vern

On 4/14/2014 12:50 PM, Steinmetz, Paul wrote:

Buck,

I agree with everything you stated, except IBM is stating this can also

occur pgm to pgm.

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

of the receiving variable, the receiving procedure or program cannot access
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 */
DCL &A *CHAR 10
CHGVAR &A 'ABCDEFGHIJ'
CALL PGMB PARM(&A) /* PASS to PGMB */
.
.
.
IF (&A *EQ ' ') THEN(...) /* THIS TEST FAILS */
ENDPGM

PGM PARM(&A) /* PGMB */
DCL &A *CHAR 5 /* THIS LEN ERROR*/
CHGVAR &A ' ' /* 5 POSITIONS ONLY; OTHERS UNAFFECTED */
RETURN
While this kind of error does not cause an escape message, variables

handled this way may function differently than expected.

If the value passed to a procedure or program is shorter than its

declared length in the receiving procedure or program, there may be more
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
structures.

If the receiving procedure or program changes the value, it operates on

the original value and on the adopted storage. The immediate effect of this
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.

In the following example, two 3-character constants are passed to the

called program. Character constants are passed with a minimum of 32
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 */

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 */
.
.
.
ENDPGM
Values passed as variables behave in exactly the same way.

In the following example, two 3-character constants are passed to the

called procedure. Only the number of characters specified are passed for
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

storage.

CALLPRC PRCA ('ABC' 'DEF') /* PASSING PROG */

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 */
.
.
.
ENDPGM

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:

midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro

Sent: Monday, April 14, 2014 12:09 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CLP pgm with 2 paramters intermittently

gettinggarbagewhencalled from AJS

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?

Yes.

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.

http://www-01.ibm.com/support/docview.wss?uid=nas8N1014767
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 :-)

--buck
--
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,

visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a

moment to review the archives at http://archive.midrange.com/midrange-l.

--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.