Re: CLP pgm with 2 paramters intermittently gettinggarbagewhencalled from AJS -- MIDRANGE-L

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.