Re: Parameter passing between programs

Hi Javier,

The problem here is the SBMJOB which has the call to your program C. It
goes back to what I would call "command entry conditions". It has no
concept of prototypes. It attempts to guess how long the parameters are
for the call to program C. It leaves off trailing blanks, so there is not
32000 bytes between the 1st and second parameter to it.

Usual solutions are:
- Create a command for the program to be the CPP of and change the
SBMJOB to execute the command rather than call the program
- Declare the long parameter to be 1 greater in the CLP doing the SBMJOB
and place an 'X' in the extra position - this will make the parameters
space out correctly but is lying in the processing

There may be other solutions.

Regards,

Kevin Wright

-----Original Message-----
From: RPG400-L<rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Javier
Sánchez
Sent: Friday, 16 August 2019 1:04 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Parameter passing between programs

"Simple answer - it doesn't.

The parameters passed to PgmB are pointers to the original storage in
PgmA. So it is likely that you are either looking at it incorrectly in
debug or else it is defined incorrectly in PgmA.

To better suggest an answer we need to see definitions and code -
including your prototype.

Plus how are you using debug to see beyond the 860 bytes?"

Jon, Dave:

Exactly, pgmB is actually a CL module, which before was an RPGLE one.

I

am using now this CL module in order to submit yet another pgmC program,
which would receive the same parameters, types and lengths.

Here is more or less the code. I could not get it out as I am working

for

a customer in a very limited access for security reasons. Using my

memory

I am pretty sure this is 99% exactly what I do:

pgmA declares this variable and procedure:

DCL-S buffer CHAR(32000) INZ;
DCL-S messageId CHAR(24) INZ;
DCL-S correlId CHAR(24) INZ;

DCL-PR ACHSJ920S; // An ILE CL module
parm_buffer CHAR(32000);
parm_messageId CHAR(24);
parm_correlId CHAR(24);
parm_responseQueue CHAR(10) CONST;
END-PR;
.
.
.
// Within pgmA I do a read to an MQ message queue with MQGET() and

populate

// buffer (with a pointer to it), and messageId and correlId. MQGET

needs

a pointer to
// buffer not buffer itself as you may already know. But this is not the
point.

//Then, call the submitting CL module:

ACHSJ920S(buffer: messageId: correlId: 'ACHPUTM');

Now, the ILE CL module ACHSJ920S would see like this:

PGM PARM(&BUFFER&MSGID&CORRID&RSPQUE)
DCL&BUFFER *CHAR 32000
DCL&MSGID *CHAR 24
DCL&CORRID *CHAR 24
DCL&RSPQUE *CHAR 10

SBMJOB CMD(CALL PGM(ACHPR920S) PARM(&BUFFER&MSGID&CORRID&RSPQUE))
ENDPGM

Program ACHPR920S (which would be pgmC) has its PR and PI like this:

DCL-PR MAINPROC EXTPROC('ACHPR920S');
parm_buffer CHAR(32000);
parm_messageId CHAR(24);
parm_correlId CHAR(24);
parm_responseQueue CHAR(10);
END-PR;

DCL-PI MAINPROC;
parm_buffer CHAR(32000);
parm_messageId CHAR(24);
parm_correlId CHAR(24);
parm_responseQueue CHAR(10)
D-PI;

Ok. When I debug, how do I see beyond the 860th character?
I write this command on the debugger's command line:

EVAL %SUBSTR(buffer 860 800)

or whatever amount of bytes to the right of it.
There is where I can see that the system displays for me, within the

same

string "buffer" the contents of parameter parm_messageId and

parm_correlId.

I would expect to see no other thing than blanks beyond that point.

Even when I debug first the CL module and I press F11 over&BUFFER I get
the same thing.

Do you think you can "lab" this to see whether you get the same results?

Thanks again.

--