Limit of CLLE parameters?

[voicucosmin90]

Hi..
Are limits regarding CLLE parameters?

I have an CLLE program like this:

PGM PARM(&PNOM &PXML)
DCL VAR(&PNOM) TYPE(*CHAR) LEN(50)
DCL VAR(&PXML) TYPE(*CHAR) LEN(50)
DCL VAR(&VAR1) TYPE(*CHAR) LEN(100)

CHGVAR VAR(&VAR1) VALUE('/home/VOICUCOSM/' +
*TCAT &PXML *TCAT '.XML')

CPYTOIMPF FROMFILE(FTEST) TOSTMF(&VAR1) +
STMFCODPAG(*PCASCII) RCDDLM(*LF) +
STRDLM(*NONE)

--->

CALL CPYTEST PARM('TEST' 'MYFILE')

but I have the values for my parameters like this in debug:

&PNOM = 'TEST MYFILE '

&PXML = 'MYFILE ' -- the first 34 characters, begin with the 35th position I have some null characters, filled with white .. see picture attached.

Thanks

[john.sev99]

I think what you are describing (the picture doesn't show anything for me) is the way the command interpreter handles padding. This always catches people.
When passing parameters in a call command, you need to pass the full character length if it's more than 32 characters. The system will automatically pad variables with spaces, but only up to 32 characters. If there are any more, junk gets added. As your parameter definitions are 50 characters long, what will get passed is unpredictable (in IBMs vernacular). You will therefore need to either:

Call it with the additional spaces:
CALL CPYTEST PARM('TEST ' 'MYFILE ')

or create a command to call your program. A command will ensure the correct padding is done.

[Scott Klement]

The picture worked for me, and yes, shows the situation that John describes.

[tomliotta]

The photo more or less works for me, too, but it's a 2-step process that isn't clearly obvious. Click on it once to bring up an attachment page, then click the link in that page to get the image itself shown. It's composed of two sections, each showing debug displays of the variables' values.

It does seem to show results that would come from what John describes, though other circumstances could give the same. It's almost certainly what happened.

The CALL CPYTEST command in the OP would work just as described.

In short, it mostly depends on how the variables were DECLARED for the first CALL command that accepts the values as well as how the values themselves were entered. The problem here seems to be that this program was CALLed using literal values that were not declared. The CALL command could have been entered directly on a command line or through a SBMJOB command or even in a compiled program. But the only things known by the command line about the literal values are that 'TEST' is four characters long and 'MYFILE' is six characters long. The command line has no way to know that program CPYTEST is going to reference 50 bytes of memory for those values.

So basically what happens is that the values 'TEST' and 'MYFILE' get put into memory somewhere with one little twist. The default handling for character literal parms always clears at least 32 bytes of memory by padding with blanks. So both of them are useful out until the 33rd byte. When CPYTEST tries to access all the way out to the 50th byte, though, it finds unpredictable memory.

But try it like this:

CALL CPYTEST ( 'TEST                                              ' +
               'MYFILE                                            ' )

If 50 character literals are passed, you can cause all 50 bytes to be initialized as you want. (I think John wanted to show this type of example.)

Or as John also suggests, create a command for it. When you define the command parameters, it provides the declarations that the command line needs for character literals.

[john.sev99]

CALL CPYTEST ( 'TEST ' +
'MYFILE ' )

If 50 character literals are passed, you can cause all 50 bytes to be initialized as you want. (I think John wanted to show this type of example.)

Yes, I forgot to enclose it in code tags, so the spaces I entered have been stripped out :-(
And thanks for the info on the pictures, the link seems to have gone now so can't have a good look now.

[Rocky]

I've just started coding CMD's for any CLP/CLLE program that I may ever want to call from a command line - it just solves so many of these type of problems...