× 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.



It would not be correct to say that it has a 32A limitation. What is
happening is that the SBMJOB parameter CMD is stripping the trailing blanks
so it is passing

CALL PGMB PARMS('Kurt Test' 'N') instead of CALL PGMB PARMS('Kurt
Test ' 'N')

so the receiving program receives garbage. The parameter length could be up
to 32k I believe.

If the parameter is 32 bytes or less you don't have a problem because the
command process always creates any CL variable as a minimum of 32
characters. Anything greater than 32 bytes is where you run into the
problem.

As indicated the solution is to define a command or to define the field as
46a and put an * in the 46 position so it does not blank compress the
string.

Personally I don't know why SBMJOB blank trims the parameters.

On Mon, Dec 7, 2009 at 3:33 PM, Kurt Anderson
<kurt.anderson@xxxxxxxxxxxxxx>wrote:

Thanks Carel & Buck.

I did know about the 15p5, but I guess the 32a limitation (wow, talk about
small) always flew by me.

I do have a command front end, which is probably why the command works for
calling the CL, but that CL then subsequently submits another, and therein
lies the problem. Thanks for the help.

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Carel Teijgeler
Sent: Monday, December 07, 2009 4:16 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CL Parameters sharing memory?

Kurt,

Default lengths of parameters passed on a call are 15P5 for numeric
(packed, 15 with 5 decimals) and 32 for character parameters.

Different lengths of a character parameter requires a command front end to
avoid this problem.

An alternative is to pass it as a parameter one character longer than the
receiving pgm and have the last position filled with a character.

So to pass parameter &CNAME dfine it in pgm A as 46 and give it the value
"kurt test
x" (these are 46 characters.)

The receiving pgm B has the parameter defined as 45.

With regards,
Carel Tejgeler

*********** REPLY SEPARATOR ***********

On 7-12-2009 at 15:58 Kurt Anderson wrote:

I tried really hard to figure this one out on my own, but am coming up
short.

I'm on v5r4.

I have a CL that submits a CL, and it appears two of the parameters are
sharing a location in memory. Is there a limitation on the size of a
field that can be submitted to a CL? I tried searching online but wasn't
finding anything. I can get around this situation by putting the big
parameter last, but I wanted to understand why this is happening.

So when I pass a 45a and a 1a variable, the 45a variable contains both
values:
&CNAME = kurt test N

Here's my source:

TESTCL1
PGM
DCL VAR(&CNAME) TYPE(*CHAR) LEN(45) Value('kurt
test')
DCL VAR(&V51) TYPE(*CHAR) LEN(1) Value('N')

SBMJOB CMD(CALL PGM(TESTCL2) PARM(&CNAME &V51))
ENDPGM

TESTCL2
PGM PARM(&CNAME &V51)
DCL VAR(&CNAME) TYPE(*CHAR) LEN(45)
DCL VAR(&V51) TYPE(*CHAR) LEN(1)

SNDMSG MSG('&V51 = ' *CAT &V51) TOUSR(KURT)
SNDMSG MSG('&CNAME = ' *CAT &CNAME) TOUSR(KURT)
ENDPGM



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

Follow-Ups:
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.