More likely you passed "enough" non-blank characters to get what you need into the submitted job.
There isn't a "limit" to the size of a character field, other than the 20k limit to the CMD parm of SBMJOB.
There is an "issue" with how the SBMJOB and the CALL command are processed.
The CMD processor builds out the memory for the character literals that are used by the submitted job.
If the Character string is "Over" 32 bytes, then there is a good chance that the memory pointed to by the parameter does not get fully allocated to the desired size.
Say your parameter is 1024 bytes long.
The when SBMJOB parses the CALL command string, the end result may trim off the trailing x'40' blank characters from the end of the string.
So if you pass 100 non-blank characters in that parameter that was supposed to be 1024 bytes, the memory pointed to by the parameter will only have allocated enough space for the 100 bytes.
But the submitted job's program will still expect that pointer to point to the entire 1024 bytes for the variable.
That becomes an issue because then the job starts and the program expects the memory to point to the full 1024 bytes.
But instead the memory after those 100 bytes is now occupied by other items in memory.
Like any additional parameters that may be passed to the CLLE program.
So if you had 3 parms
PGM PARM(&P#ERRORDS &P#DATE &P#SORTBY)
DCL VAR(&P#ERRORDS) TYPE(*CHAR) LEN(272)
DCL VAR(&P#DATE TYPE(*CHAR) LEN(10)
DCL VAR(&P#SORTBY) TYPE(*CHAR) LEN(1)
Say you had a submit in a CLLE program.
SBMJOB CMD(CALL PGM(NAME) PARM(&P#ERRORDS &P#DATE &P#SORTBY)) JOB(NAME)
Now, if &P#ERRORDS contained "HELLO".
&P#DATE was '2021-10-15',
AND &P#SORTBY was "A".
Then when the program starts, your variable &P#ERRORDS may actually contain something like this
"HELLOW 2021-10-15A........"
The reason is because the system compresses out all the trailing blanks from the character literal when it gets submitted.
I've seen instances where it gets shortened down in 32 byte chunks. So if the field had 55 characters followed by 100 blanks, you would end up with 64 characters, followed by other items in memory.
I know we've discussed this on midrange in the past, but the search is eluding me.
I did find this entry on stackoverflow.
https://stackoverflow.com/a/42675644/1958881
Now there are historically two ways to get around this dilemma.
One way is to wrap your program with a Command. (I agree with Charles it's the best way).
That way you are submitting that command instead of using the "CALL" command.
This is a good way to do it because then nothing ever gets trimmed because the command definition gives the size of all the parameters.
The other way, and sometimes the cheaper way, is to just add a trailing non-blank character to the end of each string when you run the SBMJOB command.
Create a variable that is one character greater than the input parameter.
Then set the last character of that field to something like "X" when you submit it to batch.
And I have to admit, I've used this method a lot more than creating the command.
PGM PARM(&P#ERRORDS &P#DATE &P#SORTBY)
DCL VAR(&P#ERRORDS) TYPE(*CHAR) LEN(272)
DCL VAR(&P#DATE TYPE(*CHAR) LEN(10)
DCL VAR(&P#SORTBY) TYPE(*CHAR) LEN(1)
DCL VAR(&P_ERRORDS) TYPE(*CHAR) LEN(273)
DCL VAR(&P_DATE TYPE(*CHAR) LEN(10)
DCL VAR(&P_SORTBY) TYPE(*CHAR) LEN(1)
DCL VAR(&POS) TYPE(*INT)
/* pad the submitted string with a non-blank */
CHGVAR VAR(&POS) VALUE(%LEN((&P_ERRORDS))
CHGVAR VAR(%SST(&P_ERRORDS &POS 1 )) VALUE('X')
SBMJOB CMD(CALL PGM(NAME) PARM(&P_ERRORDS &P_DATE &P_SORTBY)) JOB(.) JOBQ(.)
Now for my explanation of using the %LEN method:
I use the %LEN to get the last position of the string, then use substring to set that character.
Someone could point out that I could have just ran this with the value set in the substring:
CHGVAR VAR(%SST(&P_ERRORDS 273 1 )) VALUE('X')
I don't do that anymore because once I had to increase the size of a parameter that was used many CLLE programs.
By using the %LEN method, I was able to just change the DCL lines and not needed to change anything else.
This was even better for me, since the parameter was actually a database record.
So I put the DCL statements in a copy book and just included it into the CLLE program.
INCLUDE SRCFILE(*LIBL/QCPYSRC) SRCMBR(POSATTRCL)
Then if the file record format had to change again, I won't have to modify any of the CLLE programs. I just need to have them recompiled.
Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Alan Shore via MIDRANGE-L
Sent: Friday, October 15, 2021 1:22 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Alan Shore <ashore@xxxxxxxx>
Subject: Passing a parameter to a CLLE program in SBMJOB
Hi everyone
We are on V7r3
I am testing a program that passes a parameter into a CLLE within SBMJOB
It wasn't until I was testing that I remembered there was a limit as to the size of the parameter in this instance
Please see this web page
https://ravijraj.blogspot.com/2018/01/pass-parameters-more-than-32-byte-in.html
This blog was from January 2018. Has that number increased from 32 to a larger size?
The parameter that I am passing is 40 characters and it seems to be working okay
As always - all answers gratefully accepted
Alan Shore
Solutions Architect
IT Supply Chain Execution
midrange.com
