× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.