Passing large parameters in CL

[K.Forsythe]

Charlie, When you use SBMJOB the call to the program ends up being translated back into a string, just as if you had typed it on the command line. Since parameters are passed by reference the system only allocates 32 bytes of data for your long character field unless its actually longer than 32 (such as when you put the X at the end). The best solution is to create a command that calls this program, and change the calling program to submit that command. I hope this helped. Kevin

[tkupchinsk]

Passing large parameters in CL

Age old problem, try the following just add a little documentation. CALL PGM(MS321C1) PARM(&SAMFGL &SACMP# &SADOC &SAFOLDER '1')) Happy computing. Remember half the fun of progamming is beating the machine (i.e. its developers) at their own game.

[tkupchinsk]

Passing large parameters in CL

Don't forget to account for the '1' parameter in progam MS321C1.

[codeMeister]

Passing large parameters in CL

I have run into this same problem myself. The way around this problem without having to "trick" the program is to use the RQSDTA paramter on the SBMJOB command to pass the parameters. Modify your calling program as listed below. Note: If you are passing your long parameter in from the command line, you will still have the same problem.

---

Code

[Guest.Visitor]

Passing large parameters in CL

kforsythe wrote, "Since parameters are passed by reference the system only allocates 32 bytes of data for your long character field unless its actually longer than 32 (such as when you put the X at the end). " Actually, in the SBMJOB the parameter is (of course) passed as a value, not as a reference, since the submitted job has no way of accessing the area of memory containing the 'original' parameter value. Because it's passed as a value (as kforsythe says, "ends up being translated back into a string"), the command processor trims the actual value before putting it into the string it passes in the CMD() parameter. This is, as has been said, a known problem. If the parameter was originally specified on a command, you could define it as a variable-length parameter (specify VARY(*YES *INT2) on the PARM statement in the command source). In the CL, make the parameter length 52, since the first 2 bytes now contain the actual number of characters returned after trimming rightmost blanks. Your programs will receive the field preceded by this 2-byte binary length value. Now on the SBMJOB command, you will actually pass a 52-byte string, which will be trimmed right. Your application can look at the first two bytes to determine the length.

[kjack]

Passing large parameters in CL

I work for a software company that develops on the System i. It always been a programming standard to use RQSDTA in all CL's with a submit in order to prevent the 32 byte limitation imposed by IBM. We have a standard parameter that we pass into most programs that is over 100 bytes long. Here is another simplified example with RQSDTA: PGM PARM(&LONGPARM &ARCHIVE) DCL VAR(&LONGPARM) TYPE(*CHAR) LEN(101) DCL VAR(&ARCHIVE) TYPE(*CHAR) LEN(1) DCL VAR(&COMMAND) TYPE(*CHAR) LEN(256) /* Build &COMMAND, the parameter for RQSDTA: */ CHGVAR VAR(&COMMAND) VALUE('CALL INVOICEPRT PARM(''' *CAT + &LONGPARM *CAT ''' ''' *CAT &ARCHIVE *CAT ''')') SBMJOB JOB(INVOICE) JOBD(&JOBD) RQSDTA(&COMMAND) The 32 byte problem is an IBM "feature" that they will evidently never fix. I've got a book on CL where the author flat out states that this is a programming bug and should be addressed by Big Blue. Now let's all hold our breath!

[mpavlak]

Passing large parameters in CL

What ever happened to the LDA? (Local Data Area) We use it all the time by loading values into subscripted spaces and then retrieving them when needed. It is very stable, and is inherited by the submitted job from the submitting job. You can load, change and read the LDA EASILY from CL, RPG, etc. Only problem: you are limited to 1024 Bytes! Hope that is enough! Regards, Mike

[cversfelt@myron.com]

Passing large parameters in CL

I have a CL program that's passing four parameters including one 50-character parameter (itself received from a prior program) to another CL program via sbmjob. I checked the parms of both programs, they match. Somehow, the called program is getting strange characters when submitted. Here's what it looks like: (Calling program MS321C) PGM PARM(&SAMFGL &SACMP# &SADOC &SAFOLDER) DCL VAR(&SAMFGL) TYPE(*CHAR) LEN(2) DCL VAR(&SACMP#) TYPE(*CHAR) LEN(2) DCL VAR(&SADOC) TYPE(*CHAR) LEN(20) DCL VAR(&SAFOLDER) TYPE(*CHAR) LEN(50) SBMJOB CMD(CALL PGM(MS321C1) PARM(&SAMFGL &SACMP# &SADOC &SAFOLDER)) JOB(MS321C1) JOBQ(HOT) HOLD(*YES) Then the submitted program MS321C1 PGM PARM(&SAMFGL &SACMP# &SADOC &SAFOLDER) DCL VAR(&SAMFGL) TYPE(*CHAR) LEN(2) DCL VAR(&SACMP#) TYPE(*CHAR) LEN(2) DCL VAR(&SADOC) TYPE(*CHAR) LEN(20) DCL VAR(&SAFOLDER) TYPE(*CHAR) LEN(50) I follow MS321C in debug, and &SAFOLDER contains a value (let's say, 'FOLDER1' with spaces at the end.) As soon as it gets into the submitted job, MS321C1, suddenly there's garbage at the end of &SAFOLDER. A co-worker suggested I put an 'X' at the end of &SAFOLDER in MS321C and strip it out in MS321C1, which works, but I'm still concerned that I can't get around this without tricking the program that way. I understand this has something to do with the way parameters are passed, by pointers referring to areas in storage. You'd think the program would be smart enough to refer to a 50 character area in storage not containing garbage where blanks are passed. Why is this happening? Is there a better solution? Thanks, Charlie

[richard.oshlag@acbl.org]

Passing large parameters in CL

Ran into this same problem - in my case the field was 256 bytes - so I sent a 257 byte field with a period in byte 257. Told the receiving program the field was 256 bytes and it simply truncates the extra byte leaving a blank-filled 256 byte field. Appears to work no matter how many parameters or where the padded one is.